[Versa] Question about query

Uche Ogbuji uche.ogbuji at fourthought.com
Fri Sep 9 11:02:30 MDT 2005


On Mon, 2005-09-05 at 12:14 -0600, Michael Olson wrote:
> On Sep 4, 2005, at 6:03 PM, Uche Ogbuji wrote:
> 
> > On Sun, 2005-09-04 at 13:24 -0400, Chimezie Ogbuji wrote:
> >>> What does it mean for a Versa resource data type to be the actual
> >>> resource itself, and not just its name?  It hurts my head to try to  
> >>> make
> >>> sense of that.  I think these are just names, and therefore I draw  
> >>> the
> >>> opposite conclusion.
> >>
> >> I think of it as a name of an actual resource that resides in the
> >> underlying RDF graph.  The  last part - for me - is the more important
> >> distinction.  I guess my question is what is an example use case of a
> >> URI reference to a resource that does not exist in the RDF graph?
> >
> > As simple as
> >
> > all() -> dc:creator -> eq(<mailto:foo at yahoo.com>)
> >
> > It's possible when the query is formulated that <mailto:foo at yahoo.com>
> > is not in the graph.  According to this magic implication we're talking
> > about, this should instantly become the empty set.  Or are we saying
> > that we would *mandate* lazy determination of the value of that item?
> 
> Not at all.  The problem is you are mixing queries with function  
> arguments.  As I've said in other parts of this thread, resource  
> literals are treated differently when they are function arguments for  
> exactly the reasons that you mention.

I dislike this greatly.  Not only does it smell of an unwieldy special
case, but it also robs Versa of some of its functional language purity,
which is one of the reasons it was so easy to reason about composing
Versa ~1.0 queries.

> What I originally asked was what does this query return
> 
> <mailto:foo at yahoo.com>
> 
> Just this as a query.  From your example, it is used in the predicate  
> expression of your traverse.
> 
> In the case of the predicate of a traverse, it is logical to call it a  
> "filter".

But it's not by itself in that predicate.  It's the argument of a
function.

eq(<mailto:foo at yahoo.com>)

I don't see it as a "filter" in the above.  I see it as a value passed
to a function.

> As a top level query, I don't think that it is a "filter" as there is  
> nothing to filter.
> 
> > And what of the simple query
> >
> > <mailto:foo at yahoo.com> = <mailto:bar at yahoo.com>
> >
> 
> Why does it matter what is on the left or right side of the equals?  If  
> we decide that <uri> is a query, then you are comparing two queries in  
> the model.  If you want to compare uris then compare them as strings.

This makes your proposal feel even worse.  This would mean that resource
refs are not even proper literals.  They're magic, black box
subexpressions.

I think that's very mind-bending and strange.


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



More information about the Versa mailing list