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

From: Patrick.Stickler@nokia.com
Subject: RE: Literals (Re: model theory for RDF/S)
Date: Thu, 4 Oct 2001 11:28:03 +0300 

[...]

> To RDF, URIs are just unique, opaque strings serving as labels of
> nodes in the graph. Right?

Right at the syntactic or symbolic level, but the model theory may have
more to say.  (It doesn't have much more to say for most URIs, it turns
out, but this need not be the case for other formalisms.)

> > All this depends on the formal underpinnings of the model 
> > theory.  In Pat
> > Hayes's model theory, the graph is syntactic (or symbolic, if 
> > you prefer).
> 
> That's what I understood. Thanks for clarifying that.
> 
> > Other model theories, possibly for other formalisms, may make 
> > the semantic
> > level BE the graph!  Yet other model theories, possibly for other
> > formalisms, may not have a graph at all, even though they 
> > handle the same
> > ``information'' that RDF does.
> 
> OK, so are you then simply proposing that the RDF semantics
> not be symbolic, but based on some other model theory?
> 
> That may be where our disconnect occurred.

No.  I rather like the current RDF model theory.  One thing that a model
theory helps to do is to keep the symbolic (syntactic) and logical
(semantic) levels apart, and to provide a meaning for the symbolic level in
terms of the logical level.

(By the way, one reason that it can be hard to discuss model theory is that
the terms used are so overloaded.   One has to be very careful not to let
the informal meanings of the technical terms counter their model theoretic
definitions.)

> > Applications interact with the graph at whatever levels are 
> > allowed by the
> > API.  If the API only provides an interface to the logical 
> > meaning of the
> > graph, then there is no way to interact with the graph at any 
> > other level.
> 
> Right.
> 
> > I do agree with you that this would be an impoverished 
> > API---you do want
> > access to the symbolic or syntactic level to at least some extent.
> 
> Exactly, and one does not want to be limited to only one API. I
> likely misunderstood you saying that only the logical API should
> be available, at the very foundational level of RDF, and any symbolic
> level totally hidden or discarded as "unnecessary bits", which is
> what I objected to.
> 
> I'm all for different APIs providing access to different levels.
> 
> The question then is at what level API should URI equivalence be
> transparent?
> 
> I still don't think it is at the RDF level. Possibly RDFS, if
> and when such a more abstract query API not directly based on
> the "raw" graph and hiding such "syntactic bits" would be defined.

Here you are talking about two different kinds of levels, I think.

There are levels of expressive power, with RDF being near the bottom,
RDFS being slightly higher, DAML+OIL being quite a bit higher, and Montague
logic being very much higher (if we could devise an extension to the model
theory for Montague logic, that is).  There are also various
``representational'' levels, such as the lexical level, the syntactic
level, and the semantic level.  

One would hope that the APIs for the different expressive levels would
match up.  That is, that there would be a call for entailment, that would
have the same (or similar) arguments for both RDF and RDFS.  However, the
APIs for the different ``representational'' levels are generally quite
different.  At the lexical level there may be no calls at all---the lexical
form of RDF and RDFS documents is just not of interest!  At the syntactic
level there may be lots of calls---to return different aspects of the RDF
graph.  At the semantic level there may only be a few calls, such as
entailment, or there may be many calls, perhaps to provide different kinds
of semantic queries.

Now the model theory for RDF mandates that the only things that matter at
the semantic level are those things that matter for interpretations and
models.  One could ask, at this level whether two URIs were equivalent
given a collection of RDF interpretations, i.e., denoted the same resource
in all the interpretations.  However, this would be a very uninteresting
call, as it turns out in the RDF model theory that given a collection of
models for an RDF graph (which is, really, the only sensible way of making
collections of interpretations in RDF) two URIs are equivalent if and only
if they are syntactically identical (but not necessarily lexically
identical, given the various lexicalizations of URIs).

Now would you care to rephrase your question?

> The question then is at what level API should URI equivalence be
> transparent?

[...]

> > Let me present one possible, very limited, but theoretically 
> > adequate API.
> > Note that I do not think that this is a good API, I'm just 
> > presenting it as
> > an example.
> > 
> > The symbolic ``retrieval'' call is:
> > 
> > Regurgitate - return the graph as a (Java?) data structure 
> > using the following
> > 	      graph representation ......
> > 
> > The semantic ``retrieval'' call is:
> > 
> > Follows?(g:graph) - return the string "yes" if the graph entails g, 
> > 		    "no" otherwise
> > 
> > Both calls depend on the existence of an implicit graph that 
> > is maintained
> > somehow.  There should be operations for doing this, perhaps 
> > something like:
> > 
> > Consult(d:URI) - parse the document d and add the resulting 
> > graph to the graph
> > Augment(g:graph) - add the graph g to the graph
> > Throwaway - start over with an ``empty'' graph
> > 
> > Now that we have an API (that needs to be more-formally 
> > defined however),
> > we can talk about how everything works in practice, and 
> > whether there is
> > sufficient access to the various levels.
> 
> Taking into account your disclaimer above, this actually isn't as 
> comprehensive as most APIs provided by RDF 'engines' and doesn't
> define how "implicit" graph equivalence is defined (based on
> two resource nodes identified with different URIs equating to the 
> same "thing"). 

I would claim, strongly, that APIs that go beyond the RDF graph are
necessarily broken.  They are doing things that are not sanctioned by the
definition of RDF and thus do not deserve to be called RDF.  (Extensions of
RDF, perhaps, but not RDF.)  The above API provides a complete interface to
the syntactic level of RDF.  The Follows? call provides a reasonably
complete interface to the semantic level of RDF.  (You could add queries,
perhaps.)

Having said that, let me temper my claim a (little) bit in two ways.  The
RDF documents are vague and unclear and there may be differing opinions on
what they mean, the model theory providing only part of only one such
opinion.  (But one that may turn out to be modified to form part of the
sanctioned meaning.)  Further, the model theory does not handle
reification, so it may be missing some important stuff.


> My understanding is that the whole point of RDFS is to enable one
> to define such kinds of graph equivalences, and e.g. from the
> perspective of Prolog like inference, there are fairly straightforward
> mechanisms to implement this higher layer where graph equivalences 
> become transparent. The whole area of semantic primitives for
> relations is IMO woefully under-addressed in RDF, RDFS, and DAML
> entirely. Classes of resources are not just "equivalent". There
> are aspects of transitivity, "rank" (superordinance/subordinance),
> approximation, etc. and any layer which strives to make such relations
> transparent needs to provide the ontology and interpretive mechanisms
> to define and utilize such relations in a generalize fashion; and yes,
> according to a well defined API as well.

I'm afraid that I am completely missing what ``transparent'' is supposed to
mean, and thus I can't make sense of this.

> I agree that the RDF community could use a standard API definition
> (to maximize code reuse across multiple RDF engines) and in fact
> that API could have two levels or modes of access, "raw" or "cooked",
> the latter taking into account RDFS defined relational semantics. 
> But that "cooked" level of access should still be defined IMO in terms 
> of the "raw" graph, and an application should always be able to
> query the lower "raw" level as needed (e.g. in tracing how/where a given
> bit of knowledge was defined or the path along which it was inferred).
> 
> Eh?

Again, I don't know what cooked or raw is supposed to refer to.  If you are
asking for some sort of ``inference replay'', then you need to add a lot
more machinery to RDF or RDFS.  Without that machinery you can't
intelligently talk about inferences or proofs or derivations or anything of
the sort.

> Cheers,
> 
> Patrick

Peter F. Patel-Schneider

Received on Thursday, 4 October 2001 16:29:55 UTC