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

Pat,

- sans chapeau

I'd like to suggest that ALT does need special treatment in the model theory.

At the beginning of M&S 3.1 it says:

  Alternative   A list of resources or literals that represent alternatives
                for the (single) value of a property. Alternative might be
                used to provide alternative language translations for the
                title of a work, or to provide a list of Internet mirror
                sites at which a resource might be found. An application
                using a property whose value is an Alternative collection
                is aware that it can choose any one of the items in the list
                as appropriate

If a resource has two titles, one in French and the other in English, then
both are the titles of the work, i.e. conjunctive.  An application however,
may choose to display only one.

If software can be downloaded from several mirror sites, then that software
can be downloaded from all them, not just one of them, i.e. again conjunctive.
The idea that this example meant to express the idea that one of these sites
has the software, you can go try them to figure out which one seems a little
far fetched.

I suggest DanC is right here; the use of ALT is a hint to an application
about how it might process this information.

I suggest where M&S uses the word 'or' in this context we must be careful to
determine whether it is discussing how an application might process the
information in the model, or what the assertions actually mean.

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

I can't think of any within the context of our current thinking.

To account for it we have to introduce the idea of an application.
Lets say that a program P runs on an RDF graph G.  Lets
assume that part of P involves running subprogram P' on the value of some
property of some resource, lets call it C for container.

The semantics then of bag, alt and seq can be described as:

  if C is a Seq, execute P' on the members of C in order.
  if C is a Bag, execute P' on the members of C in any order
  if C is a Alt, execute P' on one of the members of C

Now this doesn't feel very satisfactory at all.  I don't believe
this for all possible P'.  For instance a validity checker would
check that all the members of an Alt were still valid.

Ah, maybe:  A Sequence seq implies the existence of an ordering
relation order(seq) on its members.  A Bag implies no such thing.
An Alt alt implies the existence of a function default(alt).


Brian




pat hayes wrote:
> 
> >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
> >one].
> 
> 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
> inferences?
> 
> Pat
> 
> ---------------------------------------------------------------------
> (650)859 6569 w
> (650)494 3973 h (until September)
> phayes@ai.uwf.edu
> http://www.coginst.uwf.edu/~phayes

Received on Monday, 3 September 2001 09:52:27 UTC