Datatyping (was: Requirements for a possible "RDF 2.0")

Harry Halpin wrote:
> I think pretty strongly an extensible data-typing mechanism should be
> built into RDF++. Again, the XML community has long been complaining
> about the data-typing facilities of XML Schema not being extensible,
> see this post [1].

I tend to the opposite view.  One of the things I failed to realize in time to 
put my weight behind it was that an approach to datatyping based on 
interpretation properties, which was proposed by Dan Connolly, could be as 
convenient to use, if not more so, than the current datatyping scheme, and would 
keep the core of RDF very much simpler.  This led to us adding a complex feature 
to RDF that in hindsight I'm not convinced was really needed.

But of course we are where we are, and that's not going away.

For me, I think one of the key arguments that swayed me to support the current 
datatyping approach (back when it was being added to RDF) was a comment (I think 
it was R V Guha) that if we failed to provide a mechanism that could be used by 
OWL to capture cardinality constraints (i.e. to be able to represent at least 
integer literals) then we would have failed to provide a basis upon which other 
groups could build effectively.  (I'm not defending the decision to layer OWL on 
RDF, but at that time it was a stated requirement.)  So, if we support integers, 
why not other XSD datatypes?  The rest is history (which others may recall 
differently).

In some ways, it's arguably the least attractive option:  we have the complexity 
of datatyping machinery, but not capable of capturing arbitrary datatypes.  But 
I really worry about where things end up if we try to design a fully extensible 
datatyping framework.  Where does it end?  Do we want polymorphism support, 
generics, templating mechanisms, complex aggregates of different types, mixing 
literals and non-literal nodes,...  Looking at the work on datatypes in some 
functional programming languages, it becomes clear that this is a very complex 
and subtle area.

So when you talk about an extensible datatyping mechanism, how extensible should 
it be?  My inclination would be to try and restrict the mechanisms to simple 
primitive datatypes, and then develop a set of patterns that build upon the 
basic RDF framework for more complex data.  (I think some have argued against 
using RDF to build data structures on efficiency grounds, but if there are 
well-defined patterns for this then I think it becomes possible for 
implementations to optimize their handling of these.)

If I were (hypothetically) trying to design an alterantive approach to RDF 
datatyping, given where we are now, I think I'd like to try and design a way to 
capture most if not all of the present datatyped literals capabilities and 
semantics using basic RDF triples and plain literals only (datatype URIs and 
language URIs as interpretation properties, anyone?), so we can simplify the 
base level on which other stuff is built.  Then we'd have room to experiment and 
try different patterns, without having to uproot the standards that people are 
currently using.

#g

Received on Wednesday, 20 January 2010 10:16:10 UTC