W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > June 2001

Re: #rdf-containers-syntax-ambiguity,#rdf-containers-syntax-vs-schema

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Thu, 21 Jun 2001 00:16:03 +0100
Message-ID: <3B312EB3.AA863B1D@hplb.hpl.hp.com>
To: pat hayes <phayes@ai.uwf.edu>
CC: w3c-rdfcore-wg@w3.org
Hi Pat,

pat hayes wrote:

> >In essence, rdf:li translates to rdf:_nnn where nnn is one more than the last
> >rdf:_mmm encountered in the element.
> Why? I fail to see what mandates this choice. 

Nobody said the choice was mandated.  We are making a choice.  We are
very close to making this one.  However, if you would like to suggest
a better algorithm ...

> In fact, this example
> seems to me to be broken on its face, since it shouldn't make sense
> to use rdf:_10 on an rdf:Bag.

That is a question about the triple structure used to represent bags.
The issue we are dealing here is a syntax issue.  To what triples do
we translate the XML.

There have been many concerns raised about the design of collections.
We have an issue for it:


However, there is a defined vocabulary for containers and some specific
syntactic support for that vocabulary. The issue which
is active is to determine what triples the RDF/XML represents.

> Bags don't have 10th elements, since
> they are unordered. But even if we allow this, the Bag description
> you give doesnt specify the subscript of the 1 and 11 items, so these
> have been generated arbitrarily.

See below.

> Y'all seem to be confusing the ordering of the items in the bag
> (which doesnt make sense, but never mind....) with the ordering of
> the XML items which describe the bag. But I don't see what these have
> to do with each other.  RDF triples are descriptions of something, 
>right? Other descriptions don't have any such ordering assumptions.

Absolutely right Pat.  One can write a description of a bag or any
container like this:


Here the ordering of the elements does not matter.  M&S however
includes some syntactic sugar to support the common case where the
elements in the container are numbered consecutively, e.g.


is equivalent, in terms of the triples it represents to:


and to:


The rdf:li's are translated to rdf:_1, rdf:_2.  This transformation is
done in document order. This makes it easier for example to edit the
description and insert something in the middle of a sequence.

The original proposal, to which you are responding, suggested an
unnecessarily complicated transform  from rdf:li to rdf:_nnn.  I proposed
a simplifed one in


and that is the proposal that is currently reflected in the test cases.

> Then there seems to be no difference between bags and seqs, so why do
> we have the distinction?

I wasn't around at the time this was designed but here are some thoughts
as some of the considerations that folks might have had in mind.  First
of all lets assume their was a requirement to represent both ordered
and unordered collections (bags and sequences):

How is a bag with the same value in it twice to be represented?

Lets assume we have a simple rdf:member property:


M&S isn't exactly clear on the subject, but if collections of triples form a
set, this is equivalent to:

  _:genid <rdf:member> "1" .

The fact that there were two members is lost.  This is consistent with the
view that sets of RDF statements have conjunctive semantics. a&a = a.

Also, it has been suggested that it was desirable to be able to represent
properties as XML attributes.  An element can only have one attribute of
any given name thus:

  <rdf:Bag rdf:member="1" rdf:member="2"/>

 is illegal.

> Example, the following should define the SAME bag, I presume (if not,
> why are they called 'bags'?):
> <rdf:Bag>
>    <rdf:li>a </rdf:li>
>    <rdf:li>b </rdf:li>
>    <rdf:li>c </rdf:li>
> </rdf:Bag>
> <rdf:Bag>
>    <rdf:li>a </rdf:li>
>    <rdf:li>c </rdf:li>
>    <rdf:li>b</rdf:li>
> </rdf:Bag>

These fragments of XML represent different sets of triples.  However,
the semantics of bags would suggest that the membership of these bags
is the same (overlooking the typo) as the ordering does not matter.
Hopefully that will become clearer when we provide a more formal
description of the semantics of containers.

The issues that you raise are well known and I have, shall we say,
raised my eyebrows, on occasion when the topic of conversation was

However, I think it would be helpful for now if we could put the
purely syntactic question about containers to bed, and return later
to the question of their semantics, once we have got some firmer
foundations in place.

Received on Wednesday, 20 June 2001 19:17:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:49 UTC