Uniform access in graph of RDF data

[Alexandre Blanquart]

Hi everyone,

I have been playing with Blueprints, and especially to persist RDF data in the stack. I am able to traverse the graph (actually SailGraph), and I am now wondering if there is a way to access uniformly the data.

What I am saying, is if one import RDFs or OWL data, the model in graph is different, actually the relations are different, but fundamentally on the Sail level, there is no such difference? Thus, there are as many traversing requests on SailGraph as RDF format. Any way to avoid that ?

Alex

[Joshua Shinavier]

Hi Alexandre,

Let me try to paraphrase. Whenever you add some RDF data to
Sail/SailGraph, and that data uses a new vocabulary (e.g. social
network data using FOAF, blog data using SIOC, etc.), you will have
new relationship types (edge labels) in your graph (e.g.
"http://xmlns.com/foaf/0.1/knows" or
"http://rdfs.org/sioc/ns#has_reply"). You want to know whether it's
possible to traverse the graph while ignoring the edge labels? If
that's the question, the answer is yes: in Blueprints, use the
Vertex.getEdges(Direction direction, String... labels) method without
supplying any labels. In Gremlin, use the inE or outE steps without
without supplying a label. E.g.

g.v(42).outE.inV

instead of

g.v(42).outE("http://xmlns.com/foaf/0.1/knows").inV

Is this what you're asking?

Josh

[Alexandre Blanquart]

Hi Josh,

Actually that is much more like the opposite of what I want to do. I want to have the same level of semantics on SailGraph that I can have on Sail.

E.g:

g.v("SomeClass").getTypes()

g.v("SomeClass").getProperties()

instead of 

g.v("SomeClass").out("rdf:type") 

g.v("SomeClass").in("rdfs:domain") ... or very much similar hard coded traversing paths

Moreover, the mapping in the graph is different when dealing with data related to RDF or OWL format for example : more blank nodes with OWL because of restrictions for example.

Then, the previous paths are different from one format to another, more complicated with OWL as the implementation of the W3C specification could be less straightforward.

There may be more libraries on the Sail level that could pay attention to the specifications and give more direct ways to get types and properties in my case.

However I would like to stay on the SailGraph level. Does this mean to have pipes that implement the specifications ? 

Alex

On Wednesday, August 1, 2012 8:51:24 PM UTC+2, Joshua Shinavier wrote:

Hi Alexandre,

Let me try to paraphrase.  Whenever you add some RDF data to
Sail/SailGraph, and that data uses a new vocabulary (e.g. social
network data using FOAF, blog data using SIOC, etc.), you will have
new relationship types (edge labels) in your graph (e.g.
"http://xmlns.com/foaf/0.1/knows" or
"http://rdfs.org/sioc/ns#has_reply").  You want to know whether it's
possible to traverse the graph while ignoring the edge labels?  If
that's the question, the answer is yes: in Blueprints, use the
Vertex.getEdges(Direction direction, String... labels) method without
supplying any labels.  In Gremlin, use the inE or outE steps without
without supplying a label.  E.g.

g.v(42).outE.inV

instead of

g.v(42).outE("http://xmlns.com/foaf/0.1/knows").inV

Is this what you're asking?

Josh

[Joshua Shinavier]

Now I see what you mean. Custom steps which give convenient names to
relationships based on RDFS or OWL semantics. This is more common in
Ripple, e.g.

@list types: rdf:type.
@list properties: rdfs:domain~.
@list superclasses: rdfs:subClassOf+

...but you could do something similar in Gremlin:

https://github.com/tinkerpop/gremlin/wiki/User-Defined-Steps

Yes, custom pipes should do the trick, as well. I believe you would
be the first to play with RDF-specific pipes.

Josh

[Alexandre Blanquart]

Do you have any pointer to ripple listing these custom pipes that could be materialized as well in Gremlin?

Do they implement the specifications ? meaning are they for example OWL compliant ?

Alex

On Thursday, August 2, 2012 9:47:08 AM UTC+2, Joshua Shinavier wrote:

Now I see what you mean.  Custom steps which give convenient names to
relationships based on RDFS or OWL semantics.  This is more common in
Ripple, e.g.

@list types: rdf:type.
@list properties: rdfs:domain~.
@list superclasses: rdfs:subClassOf+

...but you could do something similar in Gremlin:

    https://github.com/tinkerpop/gremlin/wiki/User-Defined-Steps

Yes, custom pipes should do the trick, as well.  I believe you would
be the first to play with RDF-specific pipes.

Josh

[Joshua Shinavier]

On Thu, Aug 2, 2012 at 5:36 AM, Alexandre Blanquart
<alex.bl...@gmail.com> wrote:
> Do you have any pointer to ripple listing these custom pipes that could be
> materialized as well in Gremlin?

Well, they're "custom" because you define them yourself, e.g. using
regular expression syntax [1]. Maybe Marko can comment on the best
way to do regex paths in Gremlin. Here's a more complete list of RDFS
steps/mappings:

@list subclasses: rdfs:subClassOf~+
@list superclasses: rdfs:subClassOf+
@list subproperties: rdfs:subPropertyOf~+
@list superproperties: rdfs:subPropertyOf+
@list properties: :superclasses? rdfs:domain~. :superproperties?
@list types: rdf:type. :superclasses?

> Do they implement the specifications ? meaning are they for example OWL
> compliant ?

If we were to add OWL (Full) semantics, we would have many more
mappings and the above would turn into something more like:

@list in-list: rdf:first~. rdf:rest~*
@list subclasses: ((rdfs:subClassOf~ (owl:unionOf. each.) (:in-list.
owl:intersectionOf~.) each. apply.)+
@list superclasses: ((rdfs:subClassOf (:in-list. owl:unionOf~.)
owl:intersectionOf) each. apply.)+
[...]

Yikes. But it can be done.


Josh


[1] https://github.com/joshsh/ripple/wiki/Syntax

[Alexandre Blanquart]

Thanks, the steps are very helpful.

On the other hand, I would like to tend to a solution with java beans, like with Frames but with classes over interfaces, which allows to map these beans to RDF statements and create only "custom" steps when it can be more difficult to get the information.

Thus, why not enjoying the Sail API and the libraries on it, like Elmo or Alibaba.

I am actually very pleased about the possibility of Elmo to retrieve the properties of a class without making any researches explicitly (with the use of Dynabean and Dynaclasses (not sure it is still possible with Alibaba though). What do you think ?

Alex

On Thursday, August 2, 2012 6:55:33 PM UTC+2, Joshua Shinavier wrote:

[Alfredo Serafini]

HI

interestin topic here.

Just a note: if i'm not wrong Elmo is going to be deprecated in some future, so i't probably more interesting and useful look at alibaba directly.

Alfredo

[Joshua Shinavier]

Hi Alex,

On Mon, Aug 6, 2012 at 3:20 AM, Alexandre Blanquart
<alex.bl...@gmail.com> wrote:
> Thanks, the steps are very helpful.
> On the other hand, I would like to tend to a solution with java beans, like
> with Frames but with classes over interfaces, which allows to map these
> beans to RDF statements and create only "custom" steps when it can be more
> difficult to get the information.
> Thus, why not enjoying the Sail API and the libraries on it, like Elmo or
> Alibaba.

If you prefer to work at the Sesame level, then I would suggest
putting your logic in a Sail-based inferencer. The Sail could then be
used with Elmo or Alibaba if you like. Sesame supports RDFS
reasoning out of the box, in the form of
ForwardChainingRDFSInferencer. This has been used effectively with
GraphSail [1]. I'm not aware of a triple-store-agnostic Sail for any
flavor of OWL, however. Someone, somewhere should really summon up
the nerve to write one sometime.

Josh


[1] https://github.com/tinkerpop/blueprints/wiki/Sail-Ouplementation