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

> > 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.

Yes. Exactly. It's not that such equivalences are not important
to the SW, they are, but rather whether they should be handled
by the RDF layer.

> > 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.

Certainly. And the utility of any given URI scheme will be in
(a) how well it supports the definition of valid syntax and
(b) how well it supports automated validation of instances.

Thus, the problem of "05" =? "5" =? "5.0" etc. can be addressed
from several directions, and the final solution can be based
on several cooperating mechanisms: URI schemes, RDFS, DAML,
localhost services, etc.

> [...]
> 
> > > ...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.  :-)

Thanks for the clarification. I guess I may have misunderstood
the communications I had with the DAML list way back when...
 
> > Do you know of any DAML system that presently does, or at 
> > least plans to?
> 
> See Peter Crowther's reply.

Yup. Thanks Peter.
 
> > > 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!  

Well, I'm not arguing here that this mapping shouldn't be done.

But should it be at the RDF level specifically? Or is this something
that might be more effectively or optimally addressed in RDFS or
higher?

The problem with opening that Pandora's Box of understanding some
URIs, is that suddenly, to be fair, you must understand *all* URIs.
And since there are not (to my admitedly poor knowledge) any current
proposals about how the semantics of URI Schemes would be defined
in a generic, portable, and RDF-compatible manner, I don't see how
it benefits us to start shifting around fundamental pillars such
as URI opaqueness unless we are darn sure that there are other pillars
first in place to hold things up, eh?

It is perhaps true that the "one URI, one resource" view could be
too simplistic or even naiive, and it likely warrants scrutiny, but
RDF also seems to get alot of milage out of it, so I don't see it
as being without value or at least some fundamental degree of
validity -- even if it needs to evolve in time to something more
comprehensive.

> ... Note also that the RDF model 
> theory does not
> embody the "one-URI, one-Resource" philosophy.  

I'm not sure I get this from the specs. Or is this part of the
recent work on "clarifying" ;-)  the specs?

> 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.

I'm not a KR person, per se, so I'm on slippery ground here, but...

From the perspective of semiotics and the three way distinction
between objects, concepts, and symbols (a'la Sowa) does not RDF deal with
symbols and not objects?

I.e. even if a given resource (object) can have multiple identities
(symbols/URIs), RDF itself is a symbol system, and since objects
themselves have no realization in RDF which could serve as an 
explicit point of intersection for equivalent symbols, if we wish to
treat multiple symbols as equivalent, we must explicitly define
that equivalence with mechanisms such as daml:equivalentTo.

It may very well be that two URLs dereference to the same byte string,
but is that within the scope of the RDF conceptual model, or is that
a characteristic of the world that needs to modelled at a higher level?

> 
> > 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?

Not two schemes, necessarily, but certainly two forms of representation 
for the same scheme -- and certainly there are other very valid and
widely used data type schemes that would have great utility on the
SW beyond what is provided in the core of XML Schema (e.g. the vast
array of IEEE standard data types, ISO standards for units of measure,
etc. etc.)

I don't think it would be prudent to take so limited a view as to
only support XML Schema data types, but rather would be wiser to
look at how various schemes for standardized data types could be
accomodated in a consistent and well defined manner.

I'm not against XML Schema data types, just about being limited
to only them.

> [...]
> > > ... 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.

Uhhh, no. Again, it's not about not allowing that patch at all, ever,
at any layer, no matter what -- but at *which* layer it *should* be 
applied. Being against it at one layer is not the same as being against
it at any layer.

I'm not against such a URI equivalence mechanism, I just don't (at the
moment) see it belonging at the fundamental RDF layer. Maybe it *does*
belong there, but I'm not convinced. 

Regards,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Nokia Research Center                 Fax:    +358 7180 35409
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com

Received on Tuesday, 2 October 2001 15:19:16 UTC