[Versa] More on literal queries

[Michael Olson]

On Sep 4, 2005, at 10:14 AM, Uche Ogbuji wrote:

> On Thu, 2005-09-01 at 12:52 -0600, Michael Olson wrote:
>> Does the this mean the following query
>>
>> "some string value"
>>
>> should only return a result if there exists a literal in the form of:
>>
>> "some string value"
>> or
>> "some string value"@some_language
>> or
>> "some string value"^^xsd:string
>>
>> ??
>>
>> same concept for number and boolean literals.
>
> I should have known.  This is straight down the rabbit hole, methinks,
> and I think maybe we're overdoing the importance of the context graph  
> in
> a Versa query.
>
> Just as I think Versa resource objects are names rather than actual
> reified RDF resources, I think that other Versa types are values rather
> than reified RDF literals.  I really do not think we want to play
> Heidegger games with Versa.


Just to be clear, we should not use the term "resource" unless we are  
talking truly about a RDF resource which are the union of

named nodes
anonymous nodes
literal values
type literals

This is discussed in section 1.3-1.5 of the semantic document,  and  
also evident from the rdf and rdfs axiomatic triples which state that  
both literal and classes are subclasses of rdf:Resource (so all  
instances of each are instances of rdf:Resource assuming support for  
the entailment rule rdfs11).

That being said, I imagine what your talking about here is you dislike  
of the simple entailment rules WRT resources, namely se1, se2 and lg  
which talk about the allocation of blank nodes for members of a  
statement.

If so, then we must decide what Versa requires as an underlying model.   
If it is simple a RDF Graph, ie a collection of triples, then Versa  
would function as you say where <uri> is just a name and the model can  
do with it what it like.  With this approach then I don't think the  
specification can talk about any semantics of RDF and is purely a  
system for querying a set of RDF triples.  ie, we could not say _Versa_  
understands the semantics around rdf:type because we do no require the  
versa data model to under stand these semantics, so type becomes yet  
another predicate in the model.  Same with transitivity of subClassOf  
or the expansion of subPropertyOf etc.

If however, we wish to support a higher level of semantics in the Versa  
language, then I see no other path then to use the rdf semantics as a  
guide.  If we don't, then how do we expect others to implement Versa as  
a RDF query language if the language itself is not designed to work  
with a RDF model?

I, of course, choose the second option because a language that only  
supports searching a set of triples is not very useful.

That being said, I don't think we need to mandate any level of  
entailment in a versa data model.  I do think we cannot limit ourselves  
to exclude implementors that wish to pursue the RDF specification in  
its fullest,  that includes thinking that a URI == a node in the graph,  
and that literals have no meaning in the graph and are just values.

My attempt in the data types section was to not limit this and vaguely  
talk about a "representation of a node" and in no way limit it to being  
either just a URI, or force it to be a "blank node allocated for the  
resource"


Mike

>
>
> --  
> 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
>
> _______________________________________________
> Versa mailing list
> Versa at lists.fourthought.com
> http://lists.fourthought.com/mailman/listinfo/versa
>
------------------------------------------------------------------------ 
-----------------
Mike Olson                                                Principal  
Consultant
mike.olson at fourthought.com                +1 720 253 4662
Fourthought, Inc.                                       
http://Fourthought.com
PO Box 270590,                                       http://4Suite.org
Louisville, CO 80027-5009, USA
XML strategy, XML tools, knowledge management