James Myers wrote:
hi jim,
> Prof Mazzochi sounds 'way off' ;-) ,
well, so be it ;)
i just thought that something like this could address michaels idea
of the bi-directional references.
Absolutely - the example was fine, I was just concerned about Stephano
being allowed to 'officially' mess with students'minds :-)
I'll continue to do it unofficially then ;-)
> but thats how I've seen references - as the way to encode RDF. I
forget how
> far we backed off in the final spec, but the idea of including a
"following'
> clause in the query language was a way to let you query along graphs.
agreed. with respect to query languages we certainly have the liberty
to extend beyond the spec in jackrabbit. but maybe jcr:deref() is what
you were looking for.
I think that's where consensus led us - jcr:deref allows you to
'manually' traverse references to find things. The 'following' clause in
the query language was intended to let you substitute named reference
relationships in for the parent/child relationship in search, so one
could formulate a query along the lines of "find all works where creator
= bob that are 'derived from' /a/b/c" where 'derived from' would be a
reference property and you'd want to recursively dereference nodes
linked by 'derived by' looking for those created by Bob. While useful,
there were/are valid concerns about this being 'expensive', 'following'
being nonstandard, etc. so it was pulled out with the possibility that
it could be added back in an alternate query language.
If we find a way to encode 'named' references, it would be possible to
write a Sparql implementation in JackRabbit and turn it into a triple store.
It if scaled and wasn't that hacky, it would make a lot of people happy,
especially because there is no standard API for adding and querying
triple stores in the java world (and there are at least 4
competing-yet-similar APIs)
At the same time, I'm not holding my breath and I don't have time to
make this happen.
--
Stefano.
