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

> I am unclear as to how this proposal would provide more simplicity or
> consistency in either the semantics or the syntax of RDF.  

Fair enough. It certainly has not been presented in any comprehensive
or organized fashion. I'll do my best to provide a more detailed discussion
with examples (a work in progress) as soon as possible.

> What I see in
> this proposal is a method for providing a general mechanism 
> for providing
> special cases for RDF.  An RDF processor would have to understand, and
> parse, all sorts of different syntax.
> 
> Consider the situation with a hypothetical integer scheme.  If an RDF
> processor is given
> 
> int:5 #loves #Susan .
> 
> and 
> 
> int:05 #loves #Jackie .
> 
> then it has to understand that int:5 and int:05 are the same
> and respond to a query about the loves of 5 that it #loves 
> both #Susan and
> #Jackie.

Well, not really (IMO)...

It is true that int:5 and int:05 would technically constitute
different URIs and hence different resources, but that's how
RDF does things, eh? Different URI, different resource. I'm
sure we don't want to shift that foundational pillar...  ;-)

Insofar as as a generalized, consistent, global representation
for a given data type, though, one would expect that there would
be constraints defined which prohibit semantically vacuous variant
forms, such as above. So yes, you bring up a very valid requirement
for e.g. an int: scheme, that we wouldn't get int:00000000005, etc.
but that's an issue for the particular scheme, not the methdology of
URI encoded literals itself, I think (apart from specifying it as
an expected quality of every such scheme to not have semanticly
vacuous variant forms).

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

> Similarly, consider the situation with a hypothetical scheme for web
> pages.  These are supposed to represent actual web pages, not 
> URIs.  If an
> RDF processor is given  
> 
> wp://www-db.research.bell-labs.com/user/pfps #loves #Susan .
> 
> and
> 
> wp://db.bell-labs.com/user/pfps #loves #Jackie .
> 
> then an RDF processor has to understand that these two are 
> the same 

Not at all. 

URIs to an RDF processor are just opaque, globally unique identifiers. 
An RDF processor does not, and should not have to understand anything 
about any URI, insofar as the semantics of the URI or URI scheme themselves 
are concerned (I stress that last clause of the assertion, re-read as
needed). 

Granted, a given RDF application will generally need to know about or infer 
(RDF defined) semantics attributed to a given URI according to one or more 
ontologies, or dereference a given URI to access additional data, 
but that is beyond the scope of RDF proper and even in the case of
dereferencing a URI, the RDF application itself does not have to understand
anything about the URI, only how to interact with an dereferencing agent
which itself understands the URI.

And furthermore, since URLs are URIs, this issue is present in 
RDF's present incarnation. 

E.g.

   http://www-db.research.bell-labs.com/user/pfps #loves #Susan .

   and
  
   http://db.bell-labs.com/user/pfps #loves #Jackie .

Same problem. Right?

The use of URI encoded literals does not itself introduce any such problem
nor complicate the problem (even if it does not solve the problem). 

If two URI strings differ in any way, than they represent different RDF 
resources, and mechanisms such as daml:equivalentTo or similar must be
employed 
to address such relationships between resources. I.e.

   <rdf:Description
rdf:about="http://www-db.research.bell-labs.com/user/pfps">
      <daml:equivalentTo rdf:resource="http://db.bell-labs.com/user/pfps"/>
   </rdf:Description>

Right?

> As far as I can see, no matter how you do it, any scheme for providing
> different semantic domains, be they integers or whatever, will require
> special purpose parsing and special purpose understanding in RDF.  The
> situation only becomes more complex in more-powerful representation
> systems.

Yet that is the present situation with RDF as it is now defined, and I
don't see how the proposed approach introduces additional complexity
or in any way makes it more difficult or involved for RDF applications
to function within the context of the fundamental "one-URI, one-Resource" 
philosophy embodied in RDF.

It does, though, make the serialization simpler, as (a) it reduces the
number of variant syntactic realizations, (b) removes (either real or
percieve) inconsistencies between the way contracted forms are mapped
to the graph for resource versus literal objects, and (c) it removes
all of the presently needed discussion about what literals are and
how they differ from other resources.

To me, that's simpler and more consistent (but I'll happily and humbly
admit that I suffer from sporatic ignorance and may very well be playing
out in la'la land on this one ;-)

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 08:02:03 UTC