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

> Somehow my point is being missed here.  

My apologies. It is likely due to my ignorance of the proper
terminology for a discussion such as this, and my not being
sufficiently competent in the field of formal semantics.

> I'm not asking that 
> RDF provide
> support for all possible URI schemes.  I'm just asking that RDF not
> preclude large classes of URI schemes, just as I'm asking that RDF not
> preclude large classes of schemes for handling literals.
> 
> That's all!!

Then I fully agree. RDF should not discriminate against any valid
URI scheme (not even those used for the namespaces of qnames ;-)

But it should also not be required to understand any URI scheme,
beyond its use as a fully opaque global identifier.

Higher application levels above RDF (RDFS, DAML, SW Agents, etc.) 
may have additional or even full knowledge about particular URI
schemes or classes of URI schemes, but explicit support for such
knowledge should not be a component of the foundational RDF
standard. IMMHO.

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

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

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

> > I guess I'm just not seeing how this works in practice, and
> > what it means to folks actually interacting with the RDF graph.
> 
> This, of course, points out a severe problem with the RDF 
> specification.
> There is no API, and thus no idea of what sorts of interactions are
> permissable with respect to the graph.  In the absence of 
> such an API many
> confusions are likely.  

Myself being a (frequent) source of example ;-)

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

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

Cheers,

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 Thursday, 4 October 2001 04:28:03 UTC