RE: Cutting the Patrician datatype knot

From: Patrick.Stickler@nokia.com
Subject: RE: Cutting the Patrician datatype knot
Date: Fri, 30 Nov 2001 19:19:44 +0200

> > > But you can use XML Schema software with the P/DAML idioms
> > > as well. 
> > 
> > Sure, but, again, why invent new mechanisms when there 
> > already are existing
> > ones for the purpose? 
> 
> I'm not. I'm actually saying the opposite, namely that the
> present RDF mechanisms are sufficient to address data typing,
> and we need not adopt still additional mechanisms, from
> any source, whether existing or not, to achieve a solution.

Which RDF mechanisms are these?  Every proposal that I have seen adds
something to RDF to handle datatypes.

> >  Particularly as this is supposed to be 
> > a standards
> > effort, and the existing mechanisms are standards from the same
> > organization?  I really don't understand this seeming 
> > aversion to using the
> > results of other W3C working groups in the RDF Core working group.
> 
> Again. I'm not against synergy between standards. I just see
> the addition of XML Schema mechanisms for defining data types
> as unnecessary as the existing RDF mechanisms do just fine, insofar
> as the PDU (P/DAML/U) idioms are concerned.

The P and DAML idioms, which I know the most about, add considerable
mechanisms to RDF Schema to incorporate datatypes.  At the very least, they
intimately depend on a datatype membership oracle and the lexical-to-value
mappings.  

Even X depends on such mappings.  Otherwise how can one determine whether

	John age xsd:integer:10 .

entails

	John age xsd:integer:010 .

> > > You don't, of course, expect the XML Schema parser
> > > to be interpreting typed data literals in the RDF serialization,
> > > right? 
> > 
> > No, I expect that the only way of typing literals, i.e., providing a
> > lexical-to-value map via syntactic means, would be via XML Schema
> > mechanisms.  I further expect that it should be possible to 
> > get *all* this
> > by passing RDF/XML through an XML parser and an XML Schema validator.
> 
> But interpretation of typed literals happens in the graph
> space, not the RDF/XML instance space. I don't see such a scenario
> as being optimal nor even plausible.

Why not?  It would be consistent to have literals in RDF graphs be the
values.

> An RDF application will interact with the graph, not the RDF/XML
> instance, and each application will realize/execute the mapping
> from lexical form to internalized value in its own way. What RDF
> has to do is provide the information that the application needs
> to achieve that. No more, no less.

Argh!!!!!!!!  I view this is a great leap backwards.  Under this view every
application will have to incorporate its own lexical-to-value mapping.  (Of
course, this would make Dan's argument concerning the size of XML Schema
implementations much more powerful.)   

Also, how could you determine entailment in this scheme.

> IMO, an XML Schema validator could only be used to validate/interpret
> XML Schema simply data typed literals by first retrieving the
> necessary knowledge from the graph, and then serializing it in
> a form meaningful to the XML Schema validator.

There are lots of other ways of doing this.  Don't rule them out by fiat.

> Surely you don't expect that all knowledge that may reside in
> an RDF graph (knowledge base) will originate from an RDF/XML
> serialization (or any serialization)? 

> Users may assert knowledge
> from a GUI, or by other serializations. Thus, requiring the use
> of XML Schema to make sense of any data typing, and restricting
> interpretation/validation of data typing to the XML serialization,
> is IMO unreasonable.

Ahh.  Certainly internal transfer of RDF data does not have to use the XML
serialization, but it also does not have to use RDF graphs.  I should be
free to write an RDF-compliant suite of tools that does not use RDF graphs
at all.  

> > > So no matter what, some application has to provide
> > > an interface between the XML Schema validator/parser and
> > > the RDF graph, and the key information that is needed is the
> > > lexical form and the URI of the data type. The interface
> > > can then provide a meaningful serialization such as
> > > 
> > >    <some:datatype>lexical form</some:datatype>
> > > 
> > > to the XML Schema parser/validator and let it "do its thing"
> > > according to some XML Schema.
> > 
> > I don't think that this is necessary, except, perhaps, for 
> > literals (text
> > nodes) that do not get types from syntactically-local mechanisms.
> 
> It is always necessary, if a generalized solution is to be achieved.
> See comments above...

I don't see how it is necessary.  There are other places for the
lexical-to-value mapping to be realized.  You yourself mention one:

Each application is responsible for the lexical-to-value mapping and must
incorporate or have access to the lexical-to-value mapping functions.

> > > The important thing is that this pairing is clearly and
> > > consistently represented in the RDF graph so that it can
> > > be provided to all applications that need it, even XML
> > > Schema applications ;-)
> > 
> > I don't see this at all.  There are *lots* of other ways to 
> > represent typed
> > literals in an RDF graph.  
> 
> The precise point is that the actual representation of such
> pairings in the graph is not as important as the pairing itself,
> and in fact the PDU approach defines three representations that
> are defined as synonymous -- all defining the same pairing.

But you don't need lexical, type pairs in the graph to do this.  You could,
for example, have actual values in the graph, not lexical items.

> I fully agree that there are lots of ways to define this
> pairing -- though we do very much need to standardize on as
> few idioms as possible to ease the burden on implementation
> and maximize portability of knowledge.
> 
> > Requiring in advance that an RDF 
> > graph represent
> > literals as pairs consisting of a datatype and a lexical form 
> > may eliminate
> > the best solution to typed literals in RDF.
> 
> I'm certainly open to considering what that "best solution" might
> be. Or do you refer to the S proposal? Note that the S proposal
> could also be viewed as defining such a pairing, but with a much
> more involved set of mechanisms. 

Most of the local solutions boil down to having some analogue of the
pairing in the graph.  I'm just saying that this is not a requirement for a
datatyping scheme.    

> Cheers,
> 
> Patrick

peter

Received on Friday, 30 November 2001 12:53:12 UTC