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

[Dion Moult]

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
-------------- 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/20110204/cc206616/attachment.pgp>