Re: Collections (Re: Misleading note about extensibiity ofCollection syntax)

At 04:20 PM 8/8/00 +0200, Pierre-Antoine CHAMPIN wrote:
>Graham Klyne wrote:
> > >rdf:Bag
> > >-------
> > >(...)
> > I agree.  It might even be called rdf:Bag (i.e. syntax-compatible with the
> > current spec).
>
>Yes, keeping the class rdf:Bag (which is already a subclass of 
>rdfs:Container) ensures compatibility, so we must keep it. But since Bags 
>have no specificity w.r.t. Containers, that class is not useful anymore. 
>That's why I prefered using rdfs:Container.

Maybe.  I am thinking that the specific class might be useful for doing 
schema-aware processing, and beyond.  I am not trying to avoid using 
schemas, just not have parsing and graph-building dependent on them.

> > >rdf:Alt
> > >-------
> > >(...)
> > 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.
>
>I think I see your point. So I think I would be happy too with rdf:Alt and 
>rdf:li.

... er, I'm now having some doubts about this.  I fear I may have confused 
*values* with *data types*.  (And I'm concerned the RDF M&S might have done 
likewise.)

As defined, rdf:Alt seems to represent a union data type, but rdf:Bag and 
rdf:Seq represent values.  A *value* of a union data type is just a single 
value.

This might make some small sense if the collection classes are used to 
describe both data values, and  corresponding data types through some kind 
of template description approach.

e.g.

    [<rdf:Bag>] --li--> [<Type>]

as a template for values like:

    [<rdf:Bag>] --li--> [value of <Type>]

OR

    [<rdf:Alt>] --li--> [<Type1>]
    [         ] --li--> [<Type2>}

as a template for values like:

    [<rdf:Bag>] --li--> [value of <Type1>]
   or
    [<rdf:Bag>] --li--> [value of <Type2>]

I'm not sure all of this is a good idea.  I think the problem is that 
<schema> wants a way to express Bag, Seq and Alt type values, but the RDF 
model itself only needs Bag and Seq.

> > >rdf:Seq
> > >-------
> > >(...)
> > 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 motivation behind the reification mechanism was illustrated in my 
>example :
>untill now, I only used Sequences when I needed an order between several 
>similar properties.
>
>I would like to avoid the trouble of having an intermediate node (the 
>Sequence resource),
>I'd rather like to specify that the order in the RDF serialization must be 
>kept in the model.
>Although reification is a bit cumbersome to handle, an appropriate API 
>could do that for me, anyway.
>
>Furthermore, that reification mechanism allows me to define Sequences as 
>we know them:
>simply the order of rdf:li properties.

I think I see where you are coming from.  There are attractions here.  If 
we can be confident that handling the reification won't become cumbersome 
then I could go with that.  I am hatching some ideas that might help.

#g

------------
Graham Klyne
(GK@ACM.ORG)

Received on Tuesday, 8 August 2000 10:59:52 UTC