[Ocs] Proposal for more flexible category hierarchy.

[Dion Moult]

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)!

-- 
Dion Moult
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/ocs/attachments/20101115/5d223f37/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/ocs/attachments/20101115/5d223f37/attachment.pgp>