<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'Monospace'; font-size:8pt; font-weight:400; font-style:normal;"> 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</body></html>