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

Re: ACTION 2001-08-24#9 : issues with containers

From: pat hayes <phayes@ai.uwf.edu>
Date: Thu, 30 Aug 2001 14:37:31 -0700
Message-Id: <v04210105b7b43697a01f@[]>
To: Dan Connolly <connolly@w3.org>
Cc: w3c-rdfcore-wg@w3.org
>pat hayes wrote:
> >
> > Re: ACTION 2001-08-24#9 Pat: Write up a summary of the issues 
>with containers
> >
> > OK, here are the ones that seem to be significant from trying to
> > incorporate containers in the MT. Note, these arise independently of
> > the matter of what rdf:li means; I'm assuming that has been somehow
> > dealt with and considering only the use of properties of the form
> > rdf:_n where n is an explicit integer, ie things of type
> > rdfs:containerMembershipProperty.
> >
> > 1. There is no way to say that some set of container contents is
> > *all* that is in a container.
>This is already on our issues list:
>  http://www.w3.org/2000/03/rdf-tracking/#rdfms-seq-representation
>There's no easy answer.
> > It seems to me that in order to be really useful, containers need
> > some such device.
>I believe so too, but the compatibility issues look hairy.

OK, I'm not up on those, but let me put another point. If there is no 
way to say or entail that a container contains *precisely* some 
collection of members, then much of what the M&S says about 
containers simply doesn't make sense. For example, the notion of 
'distributive reference' in section 3.3  (aboutEach) seems to simply 
assume that the elements of a container are the ones mentioned and no 
others, since if there could be any others then it would in general 
be impossible to compute the rdf graph corresponding to any 
particular use of aboutEach. The usage described in 3.4 is also 
obviously intended to have the 'these and no others' interpretation 
with respect to all the pages on a website.

> > 2. It isn't clear whether containers (particularly sequences) can
> > have 'gaps' or not.
>We decided (1) the spec is indeed unlear here, to
>the point of erroneous; (2) they can have gaps;
>hmm... at least: I thought we did;
>I don't see it in the issues list... and I've reviewed
>the meeting records back to May.
>Where the heck did it go? Chairs? help? Am I hallucinating?
> > I suggest we at least say whether or not it does, one way or the other.
>yes: say it does not [i.e. the gappy one does not entail the gapless

So if we say that

xxx rdf:type rdf:bag
xxx rdf:_1 aaa
xxx rdf:_3 bbb

then xxx might have just two members, even though one of them is number 3?

OK, then how, if at all, would xxx differ from yyy where

yyy rdf:type rdf:bag
yyy rdf:_1 aaa
yyy rdf:_2 bbb

Remember, these things are *bags*, so the order isn't supposed to 
matter, right? And swapping 2 and 3 is still a reordering even if 
location number 2 is 'blank'.

> > 3.  There really doesn't seem to be any actual difference between
> > bags and sequences in RDF;
>No more and no less than any two other classes, such as
>Apples and Pears.

Oh, but that is a cheap get-out. These are supposed to be something 
like datatypes, right? Not just arbitrary classes. If not, then the 
M&S is *deeply* confused, since there isn't any way to characterise 
finite datatypes in any descriptive logical language, let alone 
something as limited as RDF (existential/conjunctive). One cannot 
even define 'finite' in full FOL (or indeed any logic with an RE 
proof theory.)

>The core model theory is really, very, very simple.
>I think you're looking for more than is there.
>It's just existential conjuctive formulas over two-place
>predicates. Aside from the (P (P P)) stuff, it's
>really vanilla and basic.

Well, there are other things in the M&S that are stated informally 
but seem perfectly clear, such as that rdf:subclassof is transitive, 
domain and range refer to class membership, and the intended meanings 
of the reification constructions, no?

I see the model theory as the formalisation of the basic notion of 
meaning for the entire language. If it only specifies part of the 
language then its useless; for example, nothing can then be said 
about entailment, validity, etc. .

> > 4.  rdf:alt as described in the M&S is a crock;
>I agree that any sort of disjuctive semantics is bogus.
>But does it really say that in the spec? Hmmm... perhaps
>this text could be read that way...
>  RDF defines three kinds of collections: ordered lists,
>  called Sequences, unordered lists, called Bags, and lists
>  that represent alternatives for the (single) value of a property,
>  called Alternatives.

Could it be read any other way? See also 3.1:

"The sentence

      The source code for X11 may be found at ftp.x.org,
      ftp.cs.purdue.edu, or ftp.eu.net.

is modeled in RDF as <Figure 5, showing an alt. >"

Notice the rather clear usage of "or" in the example :-)

> > in particular,
> > because of 1., asserting a property of an Alt hardly says anything;
> > it could be true even if all the members of the alt which are
> > mentioned in the graph do not have the property, since there might be
> > some others that do. (See the latest version of the MT document for a
> > longer discussion of this.)
> >
> > Fixing 1 seems to be a prerequisite for making rdf:alt coherent in
> > the way stated in the M&S.
>Not really. It's a useful application-level construct even
>if it's not novel at the model theoretic level.
>i.e. applications can define properties, e.g. my:p with rules ala...
>	(forall (?s ?C)
>          (implies (and (rdf:type ?C rdf:Alt)
>                        (my:p ?s ?C))
>               (exists (?x ?n)
>                  (and (rdf:type ?n rdfs:ContainerMembershipProperty)
>                       (?n ?C ?x)
>                       (my:p ?s ?x) ) ) ) )
>or some such.
> >  I would  suggest that we simply trash
> > rdf:alt and suggest that our successors re-do it better.
>I think it has reasonable uses; it's just like multipart/alternative
>in MIME: the sender sends many acceptable values, and the
>receiver choses one; but this is an application level convention,
>not a logical inference from the core model theory.

I'm uncomfortable with this.  Either it is part of the language or 
not. If it is, then its meaning ought to be made clear and 
unambiguous (in the MT, ideally). If its not, then the M&S shouldnt 
have about 10%  explaining how to use it and giving examples.

Could what the application level convention 'does' with this 
construction have any conclusions that would have any logical 


(650)859 6569 w
(650)494 3973 h (until September)
Received on Thursday, 30 August 2001 17:36:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:03 UTC