[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Categories (was: ProtocolDataModel issues)



First of all I'm not at all sure categories have a place in the
protocol at all, or for that matter anywhere in core Atom.
Categorization on the web is a hard problem with different solutions
being more appropriate in some circumstances than others.

Secondly, if categories are to be considered in scope, then please can
we not mandate a hierarchical model. Trees are too restrictive to use
directly for many kinds of categorization, and often you have to make
up ugly hacks to work around them. I'm a big fan of DAGs, but I think
even such a restriction is a step too far. I go along with the idea of
the servers using whatever model they wish.

Cheers,
Danny.


On Wed, 15 Sep 2004 11:15:29 -0400, Robert Sayre <mint@xxxxxxxxxxxxxxx> wrote:
> 
> Ezra Cooper wrote:
> >
> > On Sep 14, 2004, at 2:45 PM, Robert Sayre wrote:
> >
> >> What properties does a category need?
> >> - name
> >> - URI
> >
> >
> > Do we want to model categories as hierarchical or flat, or as DAGs? If
> > flat, then hierarchical tools might have to write out long path names
> > for their categories. Do we stop at having a single parent for each
> > category, or can we allow several parents (giving rise to DAGs)? Looks
> > like there are at least two or three possible models for categories.
> >
> > I favor a hierarchical model, possibly with a fallback for tools that
> > don't want to deal with hierarchies. For the fallback, it might be
> > enough just to make sure that each category has a unique human-readable
> > name so that users can select a category without seeing the hierarchy.
> >
> 
> I meant DAG (I missed a many:parent property). We have a similar problem
> to users/principals[0] in WebDAV ACL, which defines a
> DAV:group-membership property[1]. We could revise this to:
> 
> Category
> - URI
> - many: memberOfURIs
> - many: memberURIs (can be entrys or categories)
> - name
> 
> Are you in favor of restricting categories to a hierarchical model, or
> just concerned about a requirement? I was thinking servers could
> restrict the model as they wish.
> 
> Robert Sayre
> 
> [0] http://webdav.org/specs/rfc3744.html#principal.properties
> [1] http://webdav.org/specs/rfc3744.html#rfc.section.4.4
> 
> 



-- 

http://dannyayers.com