[Versa] Issue 1, better literal and datatype support

[Uche Ogbuji]

On Fri, 2005-08-12 at 09:08 -0600, Michael Olson wrote:
> >>
> >> 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)
> >
> 
> Why.  We convert plain strings to numbers according to section 3.

Too much typing, for one thing.  Do you really want to be forced to type
'"1"^^xsd:int' rather than '1' every time?  I don't.  I'm fine with an
automated cast, but not with typed literals as a replacement for Versa
primitives (which is what Chime said int he para I responded to).


> >> 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?
> 
> You should read the spec.  There is equiality between literals.

Equality has nothing to do with identity.


> It  
> also depends on the level os support the model has.  But it is valid to  
> have two statements pointing to the same literal blank node.

That's clear from the spec, but I don't think it really makes much
difference.

> >   To what extent does this bloat the
> > model?
> >
> 
> It actually helps in so many ways (having just implemented it).  Both  
> in model size (now a statements table only needs three columns not  
> four),

You mean "column count", not "model size", right?

> interfaces, no more addStatement for literals and addStatement  
> for resources, queries, etc.

I don't understand this at all.

> I think it is a very smart move.

It may well be.  I'm just noticing this for the first time today, and it
seems to me as silly a move as reification into triples rather than
context.

> > Oh yeah.  The spec says "These rules allow blank nodes to proliferate,
> > producing highly non-lean graphs".  Nice euphemism.  Bah.
> >
> 
> I have no issues with this statement except it might not belong in a  
> specification.

I said it was a euphemism.  I don't know how that would indicate I
expect you to have an issue with it.

> Isn't it where we went with 4RDF at one time?  a literals table with a  
> foreign key from the statement table to the literal table.  exact same  
> concept...

That's implementation level, not RDF model semantics level.  Very
different matter.


> > BTW, You mentioned language specifiers.  I think we should add those as
> > well, while we're on data types.
> 
> Yep
> 
> BTW, can someone fix the reply-to on this list so we don't continually  
> get 2 copies of the message.

No.  I don't intend to turn on reply-to munging.  We don't have it on
for any of the other lists on lists.fourthought.com because I (and many
others) think it's bad form.  Even mailman agrees, having munging off as
a default, but that doesn't matter.  The debate has raged for years, and
I'm firmly on one side, and I won't administer any list with reply-to
munging (I barely tolerate being on them).

I should do a better job of trimming headers (Ctrl-L in Evolution rather
than Shift-Ctrl-R, BTW), and I shall.


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