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

Thu Feb 3 16:46:37 PST 2011

On Thursday 03 February 2011 22:24:16 Frank Karlitschek wrote:
> 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?

Yeah most definitely - but it's a necessary evil to have a big impact if we 
want to increase flexibility :)

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

I'm currently living down under and so I'm geographically opposite from 
Europe. However what are the options for joining remotely?

By the way, in case you want to play with an implementation I've done with 
these changes I've implemented the OCS using this new scheme on 
http://wipup.org/ - you can see some of the differences of implementation 
documented here: https://www.assembla.com/wiki/show/eadrax/API (basically the 
subcategories thing is the only interesting bit).

> 
> 
> 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?
> 
> --
> Frank Karlitschek
> karlitschek at kde.org
> 
> 
> 
> 
> _______________________________________________
> Ocs mailing list
> Ocs at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/ocs
-- 
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/7ea8a331/attachment.pgp>