W3C home > Mailing lists > Public > www-rdf-interest@w3.org > December 2001

RE: Cutting the Patrician datatype knot

From: <Patrick.Stickler@nokia.com>
Date: Sat, 1 Dec 2001 13:06:41 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B162285@trebe006.NOE.Nokia.com>
To: pfps@research.bell-labs.com
Cc: www-rdf-interest@w3.org

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

Because in order to have values in the RDF graph, RDF must utilize
a canonical *native* representation of those values which means
that RDF must have a built in set of data types for integer, etc.

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

I don't see how you could do it any other way. Applications
written in different programming languages and tools will
have different internalized representations for the actual
*values* and thus the mapping will have to be executed on
a case by case basis. 

Even if an XML Schema validator is used for checking the
validity of values, it is likely that the values will still
be interned in some other application that is simply 
employing the XML Schema parser/validator.

> (Of
> course, this would make Dan's argument concerning the size of 
> XML Schema
> implementations much more powerful.)   

Agreed. It's also not certain that the mechanisms provided
by XML Schema for defining data types will meet all needs
of all users (I can't offer particular examples, but the
possibility is real) and thus we should be cautious about
"putting all our eggs in one basket" by failing to have
as generalized and future proof a solution as we can achieve;
while of course maximizing the benefit of existing standards
such as XML Schema.

> 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 long as the behavior is consistent with the specs, sure. What's
under the hood is rather irrelevant. One could just view the graph
model as a way to view RDF semantics. I often take this view myself.

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

In the above quote, I was referring to the need to have
the knowledge available regarding pairings so that whenever
the lexical-to-value mapping must be done, the application
has what it needs.

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

And how would you have actual values without either (a) an RDF
native data type scheme with canonical internalized representations,
or (b) an RDF native data type scheme with canonical lexical
representations?

It is possible to implicitly represent a value in RDF, but I don't 
think it is reasonable or practical to explicitly represent a value 
in RDF.

To explicitly represent values in the graph (or wherever) in RDF
is to turn RDF into something like CORBA, where we will *still*
have to map values into the internalized representations of 
particular software applications.

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

It appears to me to be a requirement for a data typing scheme
which must preserve the lexical forms. And because RDF does not
and IMO should not have native internal representations of values,
a pairing approach seems the most efficient for preserving the
data typing knowledge until applications can use it in the context
of their own internalized data typing schemes.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Saturday, 1 December 2001 06:06:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:52 GMT