RE: Cutting the Patrician datatype knot

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

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

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

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.

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.

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.

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

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

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. 

Cheers,

Patrick

Received on Friday, 30 November 2001 12:20:01 UTC