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 22:19:03 +0300 

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

I think that you are not understanding my point.  If RDF is going to be
compatible with---not even understand, but just be compatible with---any
scheme that identifies URIs, then it cannot require that different URIs
denote different resources, or even require that different literals denote
different literal values.  Instead RDF has to admit the possibility that
different URIs denote the same thing.

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

This is the recent (excellent) RDF model theory that Pat Hayes has
produced.  In this model theory there is no requirement that different URIs
denote different resources or that different literals denote different
literal values.

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

But if RDF requires that different URLs denote/dereference
to/represent/... different things then extensions of RDF are forever stuck
with that decision.

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

Again.  If you require that DIFFERENT URIs denote DIFFERENT things you
cannot later turn around and allow any two different URIs to denote the
same thing.  You have already said that they denote different things, and
this would introduce a contradiction.

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

This has nothing to do with whether RDF has any mechanism for equivalence
or difference.  It has to do with whether anything built on top of RDF can
ever have a non-trivial theory of URI or literal equivalence.

> Regards,
> 
> Patrick

Peter F. Patel-Schneider

Received on Tuesday, 2 October 2001 15:53:32 UTC