[Versa] Question about query

[Uche Ogbuji]

On Sun, 2005-09-04 at 20:37 -0400, Chimezie Ogbuji wrote:
> > 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?
> 
> See, I would think the way I would think about it for this query would
> be to filter the dc:creator values by string comparison to the
> resource name:

Why is it string comparison if that's not a string, but rather a
resource reference?  Are you saying that Versa should not define
collations of resource references except by conversion to string
literal?  if so, what is the difference between that and my assertion
that a Versa resource ref is just a name anyway?

Why do we pick the special case of the bare query
"<mailto:foo at yahoo.com>" to be where all of a sudden the "this thing
really is the res of a resource, and not just its name" character to pop
up?

If Versa functions behave as if it's just a name, then isn't it a lot
less confusing to just make it a name throughout?


> all() - dc:creator -> eq('<mailto:foo at yahoo.com>')    
> or
> [- dc:creator -> eq('<mailto:foo at yahoo.com>')]
> 
> In which case, once again literals are actual values in the query
> space but 'resources' are matched by a uri pattern (explicit or
> qname).  The only confusion, perhaps, is the sticking point that
> literals are now resources in the model (when I say 'resource' i mean
> it in the old sense).

You're not kidding it's a sticking point.  I'd use much nastier
language.


> > all() -> dc:creator -> neq(<mailto:foo at yahoo.com>)
> 
> all() - dc:creator -> neq('<mailto:foo at yahoo.com>')

Again, if Versa functions can't do such a simple thing usefully with an
actual resource ref, until it has been converted to a string, I think
we've gone badly off the rails.

And one problem I see with your example is that it would match objects
with string literal rather than resource objects, if those string
literals happened to be spelled "<mailto:foo at yahoo.com>".  Sure such a
model might not be the best designed, but it would be perfectly valid.

> I wouldn't think you would want to interpret the use of neq (or eq)
> here to mean logical identity.

Could you rephrase that?    I don't follow.  For a start, do you mean
"interpret the use" in my example, or in the changed version you made?

> In which case you would have to
> account for 'smushing' the graph by collapsing blank nodes that
> identified the same resource via DL inferencing that produces
> owl:sameAs statements (consider that you mean foaf:mailbox instead of
> dc:creator, which is an inverse functional property that could be used
> to calculate logical identify explicitely).

I mean no such thing.  It is perfectly valid for dc:creator to have a
mailto: URL resource as its object, and that's exactly what I meant.

I think maybe this is where we're walking different paths.  To me, it
makes sense that eq(resource-ref) is an identity peration, based on what
the back end computes as identity (i.e. are entailments applied).
eq(string-val) would not be an identity operation, and would check
whether the resources can be converted to that string val, either by
resource name or literal name.


> This is much more
> complicated than comparing the string representation of a uri
> reference against another string.
> 
> I guess my question is given how RDF has now changed, with regard to
> literals and resources both being in the same class, will it ever be
> reasonable to expect to be able to compare resources and literal not
> by the string representation of their URI but by logical identify
> (log:equalTo and owl:sameAs)?
> 
> 
> Maybe I should pick the brains of some folx in #swig

You and Mike might be right about the changed character of RDF.  I
suppose I should find out.  If RDF really has made it so hard to reason
about such basic matters of records semantics, then I personally have
bigger matters to consider (i.e. whether RDF is worth using, at all),
and I perhaps shouldn't hold you guys back with my old school thinking.


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