RE: SEM: 5.5 List semantics

Pat, can you elaborate more? I would tend to agree with Peter here, defining yet another string way seems redundant. (Moreover, even
architecturally, what are RDF lists there for, then?)
Can you be more specific on the problems?

if RDF had complex datatypes, this could be done quite elegantly ;)


> -----Original Message-----
> From:
> []On Behalf Of Peter F.
> Patel-Schneider
> Sent: Thursday, October 31, 2002 1:48 PM
> To:
> Cc:
> Subject: Re: SEM: 5.5 List semantics
> From: pat hayes <>
> Subject: Re: SEM: 5.5 List semantics
> Date: Wed, 30 Oct 2002 22:40:37 -0600
> > >I PROPOSE that OWL augment the characterization of the RDF List vocabulary
> > >so that it serves the needed purpose for OWL.   The technical details for
> > >this augmentation can be found in
> > >
> > >
> > >
> > >I PROPOSE that there be no owl:List, owl:first, owl:rest, or owl:nil.
> >
> > That won't work.
> For this statement to be true, it must be the case that the RDFS model
> theory is constructed in such a way so as to make it impossible to impose
> semantic conditions on rdf:List, rdf:first, rdf:rest, and rdf:nil that
> serve the purposes required for OWL.  I don't see how this can be so.
> > The proposed semantics for the RDF list vocabulary
> > is an empty semantics. There will be no restrictions on lists:
> In particular, there are so few (no) conditions on the RDF list vocabulary
> that essentially nothing is ruled out.  All that the OWL model theory has
> to do is to state the conditions that OWL needs on lists.
> > they
> > can have multiple heads, forking tails, rdf:nil can have countably
> > many rdf:rest properties. All manner of 'impossible' things will be
> > allowed. The resulting structures will bear no semantic or syntactic
> > relationship to Lisp-style lists in the usual sense at all: they will
> > be arbitrary graph structures linked by the list vocabulary names in
> > arbitrary ways. Recursive algorithms will not work on them.
> So, the OWL model theory can simply disallow these situations, if that is
> what is required.  (However, I do not believe that all this is needed, at
> least for Fast OWL.)
> > In order to use this coherently in OWL we will still need owl:List (a
> > subclass of rdf:List, analogous to owl:Thing a subclass of
> > rdf:Resource) and owl:nil (distinct from rdf:nil, which can be in the
> > domain of rdf:rest and hence cannot be used as an end-of-list marker
> > in OWL), and we will need to essentially axiomatize Sexpressions in
> > OWL. So the OWL list vocabulary will be, at best
> >
> > owl:List rdf:first rdf:rest owl:nil
> >
> > which it seems to me is a bad decision on almost all grounds. Im not
> > even sure if we can use rdf:first and rdf: rest, since other
> > applications might consistently assume that a list can have, say,
> > three rdf:firsts; that would be consistent with the proposed RDF
> > specs.
> > It is a violation of the RDF spec for OWL to impose extra
> > meaning on something in the RDF namespace, so OWL should use its own
> > properties and subproperty them to the RDF list properties.
> Aha!  Here is my point of divergence.  Where does the RDF spec prohibit such
> conditions in the OWL model theory?  The OWL model theory imposes extra
> meaning on lots of the RDF namespace, including rdf:type, rdfs:Class, and
> rdf:Property.  Is this illegal?  If so, there is no way to provide an
> RDFS-compatible meaning for OWL.
> > I therefore PROPOSE instead that OWL totally ignore the RDF list
> > vocabulary, which will not have a semantics adequate for OWL
> > purposes, and instead revert to using its own list vocabulary.
> >
> > >I maintain that this sort of augmentation is entirely in keeping the
> > >entirely of the RDF(S) philosophy.
> >
> > It would be if it could be made to work, but I do not believe it can be.
> Why could it not be made to work?
> I don't see any technical problem with the semantic characterization in
> > Pat
> >
> > PS. I have BCCd this message to the RDF core WG for information purposes.
> peter

Received on Thursday, 31 October 2002 10:21:21 UTC