How do I construct get the whole sub graph from a given resource in RDF Graph?

Question

If this is the RDF graph , given the resource A , I need to construct all the triples connected to A till the end . here i have to get the graph include B,C,D,E

After that, suppose I've got this graph and want to go only from the starting point (:A) and get the subgraph produced by following the paths that end with an edge on property :d. For instance, if A1 is given as the starting point, and d as the property, we'd construct:

:A1 :a :B1, 
:B1 :b :S1,
:B1 :b :S2,
:S1 :d :D1,
:S2 :d :D2,

Livesay

Answer 1

The first case

To get the whole connected graph, you need to use a wildcard property path to follow most of the path, and then grab the last link with an actual variable. I usually use the empty relative path in constructing wildcards, so as to use <>|!<> as the wildcard, but since you mentioned that your endpoint doesn't like it, you can use any absolute IRI that you like, too. E.g.,

prefix x: <urn:ex:>

construct { ?s ?p ?o }
where { :A (x:|!x:)* ?s . ?s ?p ?o . }

This works because every property is either x: or not, so x:|!x: matches every property, and then (x:|!x:)* is an arbitrary length path, including paths of length zero, which means that ?s will be bound to everything reachable from :a, including :a itself. Then you're grabbing the triples where ?s is the subject. When you construct the graph of all those triples, you get the subgraph that you're looking for.

Here's an example based on the graph you showed. I used different properties for different edges to show that it works, but this will work if they're all the same, too.

@prefix : <urn:ex:> .

:A :p :B, :C .
:B :q :D .
:C :r :E .

:F :s :G .
:G :t :H .

prefix x: <urn:ex:>
prefix : <urn:ex:>

construct {
  ?s ?p ?o
}
where {
  :A (x:|!x:)* ?s .
  ?s ?p ?o .
}

Since this is a construct query, the result is a graph, not a "table". It contains the triples we'd expect:

@prefix :      <urn:ex:> .

:C      :r      :E .

:B      :q      :D .

:A      :p      :B , :C .

The second case

If you want to ensure that the paths end in a particular kind of edge, you can do that too. If you only want the paths from A1 to those ending with edges on d, you can do:

prefix x: <urn:ex:>      #-- arbitrary, used for the property path.
prefix : <...>           #-- whatever you need for your data.

construct {
  ?s1 ?p ?o1 .           #-- internal edge in the path
  ?s2 :d ?o2 .           #-- final edge in the path
}
where {
  :A (x:|!x:)* ?s1 .     #-- start at :A and go any length into the path
  ?s1 ?p ?o1 .           #-- get the triple from within the path, but make
  ?o1 (x:|!x:)* ?s2 .    #-- sure that from ?o1 you can get to to some other
  ?s2 :d ?o2 .           #-- ?s2 that's related to an ?o2 by property :d .
}

Hachmann

I used the query u have suggested me, the SPARQL gives me an error saying Not a valid (absolute) IRI: – Livesay

@Livesay probaby the SPARQL engine you use does not accept an 'empty' IRI (<>) as valid. But the solution works with whatever IRI you pick, so you can simply replace <>|!<> with, for example <urn:foo>|!<urn:foo> to make it work. – Postorbital

You're following the properties only in one direction, :B is part of the same connected graph as :A but you wouldn't get the same result when inserting :B instead of :A in your query. Also if you add the triple :F :r :C to the graph it wouldn't be returned by your query, even though it is connected to A. So I'm still waiting to see the query that returns the connected subgraph for any given resource. – Thanos

@Reto The desired output from the OP suggested that triples pointed left to right and were only to be followed in the forward direction. But this can easily be made to work in both directions. Just change the wildcard path to ((<>|!<>)|^(<>|!<>))* so that it can go forward or backward. – Hachmann

@JoshuaTaylor In the WHERE part, the first triple pattern is not connected to the others, i guess it should be :A (x:|!x:)* ?s1 . – Medallion

And the property path expression is syntactically wrong, the colon should be before the x. So in the end we have :x:|!:x. – Medallion

@AKSW, Yes on the ?s/?s1 issue. It should have have been :A ... ?s1. But on the x: part, the prefix I defined was x:, and the intent was to use just the prefix as the URI. Just like you could do prefix foaf: <http://....> and then use foaf: as a URI. – Hachmann

Ah sorry, I missed that you defined it as prefix. – Medallion

@amogh I'm still interested, though: you said something in the first query wasn't general enough; what didn't work about it for the first case? – Hachmann

@JoshuaTaylor the first case works too but the first ans u had given which contained the empty IRI <>|!<> did not work . I am using sparql engine of open sesame workbench and it said "Not a valid (absolute) IRI: –" – Livesay

Answer 2

The most important part of an RDF graph is the properties. Since your diagram does not define the properties, the question is rather ambiguous, but comes down to a couple of scenarios.

If the property is the same in the graph, then a transitive property path can be used:

CONSTRUCT {:A :prop ?rsc }
WHERE {
   :A :prop* ?rsc .
}

If there are multiple types pf properties in the graph, it is more complicated to get the transitive closure. For example the following will get all properties in the example graph:

CONSTRUCT {
   :A ?p ?rsc1 .
   :A ?p1 ?rsc2 .
}
WHERE {
   :A ?p ?rsc1 .
   OPTIONAL {?rsc1 ?p1 ?rsc2 .}
}

Note this goes two levels deep. For arbitrary levels, it may be best to call the following query until no new triples are created:

CONSTRUCT {
   ?rsc ?p ?o .
}
WHERE {
   ?rsc ?p ?o .
}

...where rsc is bound to :A initially and to the values for ?o for subsequent iterations.

Marocain

No the properties are not the same, and i dont even know many nodes are there after A. I just want to go till i find a Literal node. – Livesay

"For arbitrary levels, it may be best to call the following query until no new triples are created" There's no need to do that. You can get the subgraph in a single construct query. I've added an answer that shows how. – Hachmann

Answer 3

It's not possible to get the whole connected graph with one CONSTRUCT query. You'll need to run multiple queries. Even with multiple queries it gets a bit tricky when Blank Nodes are involved as you will have to gradually expand their context and return this context in every subsequent query.

For an example of some code that does exactly this, see: https://github.com/apache/clerezza-rdf-core/tree/master/impl.sparql/src/main/java/org/apache/clerezza/commons/rdf/impl/sparql.

Handed

This isn't true. You absolutely can get the subgraph with a single construct query. I've added an answer that shows how. – Hachmann

@JoshuaTaylor your query just works for the example data. I still think that in the general case you can't return the whole connected graph containing a resource with a single query. I'd be happen to be proven wrong, but your answer doesn’t provide this. – Thanos

it does actually. The triples conducted by the query I provided are all the triples reachable from n the starting point. If you can come up with a countable of a case that this doesn't handle, I'd gladly welcome it, though. Do you have an idea where it wouldn't work? – Hachmann

@JoshuaTaylor, the question asks for a query returning the whole subgraph not the tree starting at a specific resource. prefix x: <urn:ex:> prefix : <urn:ex:> construct { ?s ?p ?o } where { :B (x:|!x:)* ?s . ?s ?p ?o . } will only return a single triple rather than the whole connected subgraph of :B. Changing the path to ((x:|!x:)|^(x:|!x:))* causes blazegraph to return all triples, not just the connected one (prefix x: <urn:ex:> prefix : <urn:ex:> ASK { :A ((x:|!x:)|^(x:|!x:))* :H . } returns true, I guess thats a blazegraph issue, I'll contact them) – Thanos

the pattern :B (x:|!x:)* ?s . ?s ?p ?o . will produce more than one triple, because ?s gets bound to everything reachable from :B. You're you're right that it is a tree rooted at :B. To go in both directions, like I described in my answer, you just need to make the path go in both directions, with a path like ((x:|!x:)|^(x:|!x:))*. That will follow any property in either direction. The behavior you're describing in Blazegraph sounds like a bug. – Hachmann

I agree that it's a bug in blazegraph, I raised an issue there. As for the first pattern it just happens to return one triple as the tree rooted in :B only has one triple. Is there a way to have your queries stop at blank nodes to get the (symmetric) CBD of a resource? – Thanos

have a look at my answer to a question on answers.semanticweb that talks about exactly that: answers.semanticweb.com/questions/26220/… – Hachmann