W3C home > Mailing lists > Public > www-rdf-comments@w3.org > July to September 2000

Re: Collections (Re: Misleading note about extensibiity of Collection syntax)

From: Graham Klyne <GK@dial.pipex.com>
Date: Tue, 08 Aug 2000 14:25:52 +0100
Message-Id: <>
To: Pierre-Antoine CHAMPIN <champin@bat710.univ-lyon1.fr>
Cc: www-rdf-comments@w3.org
At 11:14 AM 8/8/00 +0200, Pierre-Antoine CHAMPIN wrote:
>Indeed a useful construct. But since order does not matter in bags, why 
>using rdf:_n properties.
>I'd rather have :
>  a class  rdfs:Container  with no syntactical influence
>  a property  rdf:li  with rdfs:Container as its domain, to link a 
> container to its items

I agree.  It might even be called rdf:Bag (i.e. syntax-compatible with the 
current spec).

>That one is a high level concept - higher than Bag or Seq IMHO: it implies 
>a "choice", but *who* has to choose and *why* ? This is a concern of the 
>application, not of the language.

I don't agree here.  I think the term "choice" is unfortunate.  To me, it 
simple implies a union type.  I would be happy with rdf:Alt and rdf:li, in 
syntax and model.

>Anyway, the main feature of that construct is to allow the expression of a 
>*default* element in a container (curently the rdf:_1 item). We could add
>  a property  rdf:default  with rdfs:Container as its domain, to point to 
> the default value.
>                           it could even be a subproperty of rdf:li.

I agree with this bit.

>Another useful construct, since it is the only way to put an order in RDF.
>Anyway, as mentioned above, I don't quite like the idea of an infinite 
>number of properties.
>I think reification could achieve it much more elegantly :
>  [rdf:Seq] <--(rdf:type)-- [someSeq] --(rdf:li)--> [Item1]
>                                |           |
>                                |       (rdf:rank)--> "1"
>                                |
>                                \-------(rdf:li)--> [Item2]
>                                            |
>                                        (rdf:rank)--> "2"
>So there should be
>  a property  rdf:rank  with rdf:Statement as its domain.
>Those reified statements and their rdf:rank properties should be generated 
>by the parser when needed,
>which implies some meta-language feature to request it. For example, a tag 
>rdf:OrderedDescription to be used instead of rdf:Description when the 
>order of the properties matter.

Hmmm, interesting.  I'm not so sure about invoking reification in this 
way.  I'll think about it some more.  Meanwhile, here are two other approaches:

(1) For an ordered list, I would be content to see "_1", "_2", etc. in the 
syntax (rather than implied by the subject container class and rdf:li).

(2) Use a LISP-like approach:

     [<Cons>] --head--> [Item1]
     [      ]
     [      ] --tail--> [<Cons>] --head--> [Item2]
                        [      ]
                        [      ] --tail--> etc.

     The sequence would be terminated by a Cons without a tail.


>An advantage is that order could be put in any RDF structure, not only 
><rdf:Descritpion about="people:john" xmlns:ps="http://schemas.org/people/">
>   <rdf:type rdf:resource="http://schemas.org/people/Man"/>
>   <ps:firstName> John </ps:firstName>
>   <ps:lastName>  Smith </ps:lastName>
>   <ps:birthDate> 1/1/1970 </ps:birthDate>
><rdf:OrderedDescription about="people:john">
>   <ps:daughter rdf:resource="people:mary"/>
>   <ps:son      rdf:resource="people:paul"/>
>   <ps:daughter rdf:resource="people:lucy"/>
><rdf:OrderedDescription about="people:john">
>   <ps:likes> Eating chocolate </ps:likes>
>   <ps:likes> Watching movies </ps:likes>
>   <ps:likes> Playing tennis </ps:likes>
>Whe would have a resource people:john with 10 properties, in which 3 
>children are ordered (supposedly by age) and 3 "likes" are ordered 
>(supposedly by preference).
>  any comments welcome
>   Pierre-Antoine
>--- Quid quid Latine dictum sit, altum viditur
>     Whatever is said in Latin sounds important.

Graham Klyne
Received on Tuesday, 8 August 2000 09:47:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:15:13 UTC