jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Jackrabbit with RDF facilities
Date Mon, 07 Feb 2005 18:00:53 GMT
Boy, it's my lucky day today :-)

antonio.lopez@ptbsl.com wrote:
> Hello all
> 
> We are a small group of programmers trying to develop sort of Model 
> Driven Architecture.
> With this porpouse we've developed a brand new rdf api and the hole 
> platform (models included) are RDF instead of MOF.
> We agree 100% with this article 
> (http://www.betaversion.org/~stefano/linotype/news/46/)

I do too ;-)

> We think jackrabbit its the perfect tool to mantain the desing 
> information (RDF models) and we think it would be very
> valuable to have some RDF facilities, for instance:
> 
>    * Make searches with *sparQL* or even our modifed api *perVERSA*
>      (base on vesa).
 >
>    * RDF import/export  funtionality would be very usefull, not just
>      XML sintax but N3 or even TRIX .
 >
> If you consider interesting this features we could help.

I planned to talk to David about RDF support in JackRabbit in 
switzerland in two weeks (we'll be speaking at the same conference), but 
now that the cat is out of the bag, I'll throw in my 2 cents.

JSR170 deals very well with namespaced content and therefore is able to 
digest and consume all RDF/XML that you can throw at it.

Writing an RDF import/export facility is therefore not more difficult 
than hooking up an RDF parser (Sesame Rio would be my choice) and decide 
how to encode the RDF into the JCR node space.

No changes are required to the spec, even if, I have to say, if I had to 
start over I would add the ability to "type" the relationships between 
nested nodes, but it's too late for this round and we can work around that.

As for querying, once the RDF is normalized into a JCR environment, 
XPath can be used to query that RDF model, but it's going to be suboptimal.

Implementing a SparQL query interface would be very interesting to have, 
but what it's unclear to me, is how the non-RDF part of the JCR tree 
(well, graph really) will look like from a SparQL point of view.

I mean, if I have a document like

  <a about="...">
   <b>blah</b>
  </a>

and I consider this to be XML, the JCR encoding will be something like

  node[a]^element
   +- property[about]^attribute='...'
   +- node[b]^element
       +-property[text()]^string='blah'

if I consider the above to be RDF, the JCR encoding will be something like

  node[resource]^uri='...'
   +- property[type]^uri='#a'
   +- property[#b]^string='blah'

note how the same exact document yields such different JCR nodes and 
properties.

But the real question is: given an XML document and an RDF/XML document, 
what does it mean to query both with the same query language? using 
xpath on RDF/XML feels weird but the same thing can be said for using 
Sparql on top of an XML tree.

At the end of the day, adding RDF support to a JCR repository is clearly 
doable, but I'm not sure it makes all that much sense.

-- 
Stefano.


Mime
View raw message