RE: Literals (Re: model theory for RDF/S)

From: Patrick.Stickler@nokia.com
Subject: RE: Literals (Re: model theory for RDF/S)
Date: Tue, 2 Oct 2001 16:33:02 +0300 

> > -----Original Message-----
> > From: ext Peter F. Patel-Schneider 
> > [mailto:pfps@research.bell-labs.com]
> > Sent: 02 October, 2001 15:41
> > To: Stickler Patrick (NRC/Tampere)
> > Cc: drew.mcdermott@yale.edu; www-rdf-logic@w3.org
> > Subject: RE: Literals (Re: model theory for RDF/S)

> > > And on a practical level, one would not necessarily expect URI 
> > > encoded literals to act as the subject of statements, or to
> > > serve as indirect identifiers of other resources, even if 
> > technically
> > > they could be coerced to do so (and regardless of whether they
> > > were guarunteed to be free of semantically vacuous variant forms).
> > 
> > Even if they are just objects of triples, you can run into problems.
> > 
> > Consider
> > 
> > #Susan #favorite-integer int:05 .
> > #Susan #favorite-integer int:5 .
> > 
> > how is an RDF query system supposed to respond when asked 
> > about Susan's
> > favorite integers?
> 
> Good point. But again, that has nothing to do with the proposed encoding
> of literals as URIs. The very same problem exists with
> 
>  #Susan #favorite-integer "05" .
>  #Susan #favorite-integer "5" .
>  
> Right?

I agree with Peter Crowther's reply, with the following additions.

If all an RDF processor has been given is

 #Susan #favorite-integer "05" .
 #Susan #favorite-integer "5" .

then there is no way for it to know that the two literals above are
integers, or reals, or strings, or whatever.  The poor RDF processor has to
allow for any of these possibilities, and so must not commit to any of
them.

If, by some means, more information is gathered about these literals, say
by the RDFS statement

 #favorite-integer rdfs:type xsd:integer .

then the situation becomes very different for a datatype-aware RDFS
processor. It now can rule out the other possibilities, interpret both "05"
and "5" as integers, and determine that these two literals denote the same
literal value.

> In any case, with literals as URIs, one can enforce that e.g. "05" is
> not legal and thus achieve a more robust system (even if the only
> action is to signal an error and/or disregard the statement).

For some URI schemes this may be valid, but there are many possible URI
schemes where identity is not determinable by the syntactic form of the
URI.

[...]

> > ...A DAML+OIL (March 2001) processor has to 
> > understand a portion of
> > XML Schema, not just the syntax but also the semantics.
> 
> Really? I thought it just borrowed the URI defined identity of
> the XML Schema data types. I once asked if a DAML parser had
> to also include that subset of functionality of XML Schema
> for dealing with data types -- particularly user defined
> data types, and was told a clear "no". Not that it couldn't,
> but it didn't have to.
> 
> Maybe things have changed?

The datatype extension to DAML+OIL (embodied in the March 2001 version)
mandates some knowledge of XML Schema datatypes.  In particular, if two
literals are known to be xsd:integer and map onto the same integer using
the XML Schema datatype mapping from literals (or whatever XML Schema calls
the syntactic form of these things) to values, then they are the same and
any consequences of this have to be addressed by a DAML+OIL (March 2001)
processor.  Whether this version of DAML+OIL becomes a supported version is
subject to lots of outside considerations.  :-)

> Do you know of any DAML system that presently does, or at 
> least plans to?

See Peter Crowther's reply.

> > It is true that you can make a consistent view of all this from this
> > ``RDF'' viewpoint, but you do have to be a bit careful.  In 
> > particular, if
> > you want to allow RDF to be consistent with different URI 
> > schemes, you have
> > to modify the "one-URI, one-Resource" philosophy to a 
> > "one-URI, possibly
> > one-Resource".  
> 
> Maybe, but that is yet another issue.

No!!!  If RDF is to have any support for URI schemes that have a built-in
semantics that maps different URIs into the same semantic object, then it
will HAVE to admit the possibility that different URIs map into the same
resource.  To do anything other is to be WRONG!  

Note that it is (barely) possible to keep the "one-URI, one-Resource"
slogan by redefining the meaning of RDF query answers, and, possibly, other
things, but this is essentially equivalent to abandoning the "one-URI,
one-Resource" philosophy.  Note also that the RDF model theory does not
embody the "one-URI, one-Resource" philosophy.  Note further that if RDF
retains the "one-URI, one-Resource" philosophy then daml:equivalentTo is
not very useful as an extension to RDF, as it will introduce
inconsistencies unless applied to equal URIs.

[...]

> > ...it does mean that RDF moves further away from 
> > the XML / XML
> > Schema way of representing literals and datatypes.
> 
> Though I'm all for standardization (heck that's why I
> spend so much time working on standards stuff) I'm not
> so sure that we want to necessarily adopt XML Schema
> data types as the fundamental data type framework for
> the entire web. Maybe. Maybe not. But in any case, that
> is still yet another issue ;-)

Agreed.  But I was under the impression that XML Schema is the method
officially blessed by W3C for representing typed (and structured) data.

> Even if we adopted XML Schema data types, we could benefit
> from URI encoded literals. The two are not inter-dependent.

Not completely, no, but why have two schemes for roughly the same thing?

[...]
> > ... but if you stick with this 
> > philosophy I don't
> > think that you can claim to be representing anything besides 
> > uninterpreted
> > URIs.  
> 
> Or rather, its a question about at what functional layer
> you wish to add that "patch" and address the URI equivalence
> issue.

No, the problem is if you require that different URIs map to different
resources, then you can't patch the problem.  If you remain uncommitted,
then there is the possibility of a patch.

[...]

> Cheers,
> 
> Patrick

Peter F. Patel-Schneider

Received on Tuesday, 2 October 2001 12:43:32 UTC