[Versa] Issue 1, better literal and datatype support

[Uche Ogbuji]

On Fri, 2005-08-12 at 09:23 -0400, Chimezie Ogbuji wrote:
> On 8/12/05, Michael Olson <Mike.Olson at fourthought.com> wrote:
> > 
> > I'd like to propose adding better literal and data type support to
> > Versa.  I don't think we need to do too much to the spec itself to
> > support this.  One thing we need is a literal data type.  This would be
> > a representation of a plain (with or without language) or typed
> > literal.  I think we leave hard issues like comparison and sorting
> > between typed literals to the underlying model.  If the model support
> > D-entailment then it can properly compare "01"^^xsd:int and
> > "1"^^xsd:int.  If it doesn't....
> 
> I had exactly the same suggestion.  So your suggestion a literal
> datatype as a *replacement* for strings and numbers?  If so, I'd
> agree, since that would completely cover all literals (especially if
> we include the capablity to associate xsd - or other - datatypes to
> the underlying model) and would be more inline with RDF Literals.

I don't know.  I think that would suck in syntactic terms.  In cases
such as

length($mylist, 1)

That 1 is more at the Versa layer, and I don't think it should be
changed to 

length($mylist, "1"^^xsd:int)


> > Besides the addition of the literal datatype, I think all that is
> > needed is to determine how the conversions work (should be pretty
> > straight forward) and some functions.  ie. it would be nice to filter
> > on language and/or datatype in a traversal.
> 
> Luckily, I think there is alot of precedent on this (with XQuery's use
> of datatypes and SPARQL's - the latter simply burrows from XQuery):
> 
> http://www.w3.org/TR/xpath-functions/#casting-from-primitive-to-primitive
>  
> > One last thing, we would need to allow these literals as "subjects" in
> > traversals.  This does not mean much from the specification point of
> > view, maybe just a mention, but implementors will need to understand
> > this.
> 
> I agree, and I think this becomes neccessary once you allow datatyping
> because of RDFs entailment rules
> (http://www.w3.org/TR/rdf-mt/#simpleRules  - rdfs1) and RDF Literals.

Right.

> Specifically:
> 
> uuu aaa lll (where lll is a plain literal (with or without a language tag)
> 
> implies
> 
>  _:nnn rdf:type rdfs:Literal .
> 
> where _:nnn identifies a blank node allocated to lll by rule rule lg.
> 
> So, the literals themselves are thought of as resources by the RDF
> model (especially if they are typed)

Did the latest RDF specs really do that?  That's really bloody messy.
So to what extent do these magic blank nodes confer identity on
(previously identified) literals?  To what extent does this bloat the
model?

Oh yeah.  The spec says "These rules allow blank nodes to proliferate,
producing highly non-lean graphs".  Nice euphemism.  Bah.

BTW, You mentioned language specifiers.  I think we should add those as
well, while we're on data types.


-- 
Uche Ogbuji                               Fourthought, Inc.
http://uche.ogbuji.net                    http://fourthought.com
http://copia.ogbuji.net                   http://4Suite.org
Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html
XML Output with 4Suite & Amara - http://www.xml.com/pub/a/2005/04/20/py-xml.html
Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.com/developerworks/xml/library/x-oocalc/
Schema standardization for top-down semantic transparency - http://www-128.ibm.com/developerworks/xml/library/x-think31.html