[Ocs] [SPAM] Proposal for more flexible category hierarchy.

[Frank Karlitschek]

Hi Dion,

I´m very sorry. I totally forget to answer your email.

We definitely have to improve the category system for 2.0 and I think your proposal is good.

But the changes have a quite big impact for the OCS providers. So I suggest to discuss this changes during the OCS 2.0 meeting in person also with the other people who do server implementation.
Do you think this is O.K?

I hope you have time for the ocs 2.0 meeting in the next few month. 
We hopefully can fix a date soon.


Cheers
Frank



On 03.02.2011, at 21:11, Dion Moult wrote:

> On Monday 15 November 2010 14:16:18 Dion Moult wrote:
>> I am currently implementing the OCS API on a site http://wipup.org/ which I
>> hope to integrate later in DEs.
>> 
>> However the current OCS API is quite restrictive in that it only allows a
>> CATEGORY->CONTENT 2-tier hierarchy approach. I came across this issue
>> briefly with Frank and I offer a solution. Here is the current set up for
>> the OCS spec 1.6 (the list below shows the parameters they have):
>> 
>> CATEGORY -> CONTENT
>> -id         -typeid
>> -name       -type
>>            -personid
>>            -etc
>> 
>> Of course, we can list the categories via CONTENT->Categories and the typeid
>> and type parameters show which CATEGORY the CONTENT belongs to.
>> 
>> Before I describe the solution, let me describe my scenario on my current
>> system. On WIPUP users create projects, and create updates (content) which
>> must belong to a project. Thus we have:
>> 
>> USERS -> PROJECTS -> CONTENT
>> 
>> Also, the projects are categorised into subjects such as Art, Music,
>> Programming, etc, thus we also have:
>> 
>> CATEGORY -> PROJECT -> CONTENT
>> 
>> As you see, the difference is that a PROJECT belongs to both a USER as well
>> as a CATEGORY. Another difference is that PROJECTS are dynamically created
>> and do not belong to a fixed set of results (ie, they differ for each user,
>> as well as for each category, and can be edited/removed/added by a user).
>> 
>> The solution (to the above problem, as well as other scenarios) is to
>> provide this new proposed layout:
>> 
>> CATEGORY -> SUBCATEGORY -> CONTENT
>> -personid   -personid      -personid
>> -etc        -categoryid    -categoryid (replaces typeid)
>>            -category      -category (replaces type)
>>            -etc           -subcategoryid
>>                           -subcategory
>> 
>> There are 3 big changes. The first is that we're changing the name to refer
>> directly to categories as "categoryid" and "category" instead of "type",
>> which is slightly confusing.
>> 
>> The second is that every single tier in the hierarchy can also optionally
>> belong to a user via the added "personid" parameter. This of course means
>> that things such as CONTENT->Categories must now allow the URL Argument of
>> "personid" to filter by user. This allows for systems just like User-added
>> projects in my site, or even User-added groups, User-added sections, or
>> whatever else might exist.
>> 
>> The third change is not actually directly visible in the example above, but
>> I propose that "CATEGORY" be made into a "recipe" which implementations can
>> use to fit their specific system. For example, for sites such as the
>> OpenDesktop network, they might only use:
>> 
>> CATEGORY -> CONTENT
>> 
>> Whereas another site might need:
>> 
>> CATEGORY -> SUBCATEGORY -> CONTENT
>> 
>> ... and yet another site might need:
>> 
>> CATEGORY -> SUBCATEGORY -> SUBSUBCATEGORY -> CONTENT
>> 
>> Which, if they wanted to do that, they just need to add the necessary
>> "categoryid", "subcategoryid", "subsubcategoryid" etc parameters to their
>> structure. Obviously the more categories you add, the messier it gets (which
>> suggests you rethink your site!)
>> 
>> So all we have to do is describe a single hierarchy level, and if people
>> want more hierarchies, they just need to prefix another "sub" and add the
>> necessary parameters to show the full parenthood tree.
>> 
>> So using this new system, to use a practical example, I can now solve my
>> WIPUP problem with:
>> 
>> CATEGORY -> SUBCATEGORY (PROJECT) -> CONTENT
>>            -personid (USER)
>> 
>> ... and I can call CONTENT->subcategories with the GET URL attribute of
>> "personid" to show all the projects belonging to a user, or with the GET URL
>> attribute of "categoryid" (not shown above) to show projects belonging to a
>> category. Similarly I can call CONTENT->list with the GET URL attribute of
>> "subcategory" to show all content in a single project.
>> 
>> I hope this is a extremely flexible proposal which should work for most
>> sites out there. Please let me know your comments (or
>> questions/suggestions)!
> 
> Bumpity bump?
> 
> -- 
> Dion Moult_______________________________________________
> Ocs mailing list
> Ocs at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/ocs


--
Frank Karlitschek
karlitschek at kde.org