I'm using Ontorefine within GraphDB to create RDF triples from a csv source. It seems impossible to add a rdf:type when the subject is a blank node.
When you hit the arrow in the bottom right corner of an object that is a blank node, you can type a owl:Restiction (or rdf:type owl:Restriction for that matter), but after applying, it disappears.
Even if you manually add the statement (in the JSON source) that this blank node has rdf:type owl:Restriction as property en object, it still does not create the actual triple. See picture below. The configuration is there, but the example states: empty empty. And indeed, no triple is created.
Is this in someway a feature of Ontotext, or is this a bug? In several occasions this is needed, for instance in creating a restriction in OWL.
Hello this is still present in the tool but it seems to be a purely a bug in the mapping UI . If you produce a mapping without the rdf:type and generate a SPAQRL query from that mapping, you can just add the rdf:type in the construct/insert part of the mapping query and use it to produce RDF or insert it GraphDB.
Related
I am looking to run a SPARQL query over any dataset. We dont know the names of the named graphs in the datasets.
These are lots of documentation and examples of selection from named graphs when you know the name of the named graph/s. There are examples showing listing named graphs.
We are running the Jena from Java so it would be possible to run 2 queries, the first gets the named graphs and we inject these into the 2nd.
But surely you can write a single query that reads from all named graphs when you dont know their names?
Note: we are looking to stay away from using default graph/s as their behaviour seems implementation dependent.
Example:
{
?s foaf:name ?name ;
vCard:nickname ?nickName .
}
If you want the pattern to match within one graph and wish to try each graph, use the GRAPH ?g form.
GRAPH ?g
{ ?s foaf:name ?name ;
vc:nickname ?nickName .
}
If you want to make a query where the pattern matches across named graphs, -- e.g. foaf:name in one graph and vCard:nickname in another, same subject --
then set union default graph tdb2:unionDefaultGraph true then the default graph as seen by the query is the union (actually, RDF merge - no duplicates) of all the named graphs. Use the pattern as originally given.
Fuseki configuration file extract:
:dataset_tdb2 rdf:type tdb2:DatasetTDB2 ;
tdb2:location "DB2" ;
## Optional - with union default for query and update WHERE matching.
tdb2:unionDefaultGraph true ;
.
In code, not Fuseki, the application can use Dataset.getUnionModel().
I'm trying to figure out a SPARQL query for getting all children of an object in a system based on a rdf store where links between objects might have properties, and therefore designed that every link is a separate object and is connected with corresponding objects by "parent" and "child" predicates like so (illustration link) :
#prefix o: <http://helloworld.org/object#> .
#prefix r: <http://helloworld.org/relation#> .
#prefix l: <http://helloworld.org/link#> .
l:link1-11
r:parent o:object1 ;
r:child o:object11 .
l:link1-12
r:parent o:object1 ;
r:child o:object12 .
l:link12-121
r:parent o:object12 ;
r:child o:object121 .
I'm relatively new to graph DBs so i'm not sure if such recursive query is possible with current links design (i've come up only with a finite-depth query with many unions). Is it possible to make such a query or should i somehow redo the design?
I am trying to clear all loaded graphs into my Apache Marmotta instance. I have tried several SPARQL queries to do so, but I am not able to remove the RDF/XML graph that I imported. What is the appropriate syntax to do so?
Try this query:
DELETE WHERE { ?x ?y ?z }
Be careful, as it deletes every triple in the database, including the built-in ones of Marmotta.
A couple of things I did for experimenting:
I downloaded the source code of Marmotta and used the Silver Searcher tool for searching for DELETE queries with the following command:
ag '"DELETE '
This did not help much.
I navigated to the Marmotta installation directory and watched the debug log:
tail -f marmotta-home/log/marmotta-main.log
This showed that the parser is not able to process the query DELETE DATA { ?s ?p ?o }. The exception behind the "error while executing update" was:
org.openrdf.sail.SailException: org.openrdf.rio.RDFParseException: Expected an RDF value here, found '?' [line 8]
[followed by a long stacktrace]
This shows that the parser does not allow variables in the query after DELETE DATA.
Based on a related StackOverflow answer, I tried CLEAR / CLEAR GRAPH / DROP / DROP GRAPH, but they did not work.
I tried many combinations of DELETE, *, ?s ?p ?p and accidentally managed to get it working with the DELETE WHERE construct. According to the W3C documentation:
The DELETE WHERE operation is a shortcut form for the DELETE/INSERT operation where bindings matched by the WHERE clause are used to define the triples in a graph that will be deleted.
I'm trying to understand blank nodes in turtle correctly, and I need to know if I have understood them correctly.
Suppose we had a turtle file:
#prefix sn: <....some uri...> .
_:a sn:name "person1";
sn:email "email1#test.com" .
_:b sn:name "person2";
sn:email "email2#test.com" .
_:c sn:name "person3" .
and we have SPARQL query:
PREFIX sn: <...some uri...>
SELECT ?email WHERE {
?x sn:name "person1" .
?x sn:email ?email .
}
This would only return the email of person 1, because ?x binds to the blank node label _:a... So my question is if an undefined variable ?x can still bind to a blank node that has a label, just like it would if it was not blank... So in this example, return will be:
email
--------------------------
<mailto:email1#test.com> |
Would that be correct? Thanks.
You guess correctly: in both cases (and as said I don't really see a difference between your two examples) the answer wil be only the e-mail of person 1.
A blank node is, from SPARQL's perspective, a resource like any other, and it will bind variables to a blank node in exactly the same way. So in the above example, since we know that the two statements use the same blank node as their subject (since they use the same label), they will be seen by SPARQL as being about the same subject.
One caveat: the SPARQL engine/triplestore that you use will most likely not preserve the specific blank node id a: when adding your data to a triplestore it will be replaced by some generated internal id. However, the triplestore will of course make sure that both occurrences of a in your file get replaced by the exact same generated id.
I've been testing Sesame 2.7.2 and I got a big surprise when faced to the fact that DESCRIBE queries do not include blank nodes closure [EDIT: the right term for this is CBD for concise bounded description]
If I correctly understand, the SPARQL spec is quite loose on that and says that what is returned is actually up to the provider, but I'm still surprised at the choice, since bnodes (in the results of the describe query) cannot be used in subsequent SPARQL queries.
So the question is: how can I get a closed description of a resource <uri1> without doing:
query DESCRIBE <uri1>
iterate over the result to determine which objects are blank nodes
then DESCRIBE ?b WHERE { <uri1> pred_relating_to_bnode_ ?b }
do it recursively and chaining over as long as bnodes are found
If I'm not mistaken, depth-2 bnodes would have to be described with
DESCRIBE ?b2 WHERE {<uri1> <p1&> ?b . ?b <p2> ?b2 }
unless there is a simpler way to do this?
Finally, would it not be better and simpler to let DESCRIBE return a closed description of a resource where you can still obtain the currently returned result with something like the following?
CONSTRUCT {<uri1> ?p ?o} WHERE {<uri1> ?p ?o}
EDIT: here is an example of a closed result I want to get back from Sesame
<urn:sites#1> a my:WebSite .
<urn:sites#1> my:domainName _:autos1 .
<urn:sites#1> my:online "true"^^xsd:boolean .
_:autos1 a rdf:Alt .
_:autos1 rdf:_1 _:autos2
_:autos2 my:url "192.168.2.111:15001"#fr
_:autos2 my:url "192.168.2.111:15002"#en
Currently: DESCRIBE <urn:sites#1> returns me the same result as the query CONSTRUCT WHERE {<urn:sites#1> ?p ?o}, so I get only that
<urn:sites#1> a my:WebSite .
<urn:sites#1> my:domainName _:autos1 .
<urn:sites#1> my:online "true"^^xsd:boolean .
Partial solutions using SPARQL
Based on your comments, this isn't an exact solution yet, but note that you can describe multiple things in a given describe query. For instance, given the data:
#prefix : <http://example.org/> .
:Alice :named "Alice" ;
:likes :Bill, [ :named "Carl" ;
:likes [ :named "Daphne" ]].
:Bill :likes :Elaine ;
:named "Bill" .
you can run the query:
PREFIX : <http://example.org/>
describe :Alice ?object where {
:Alice :likes* ?object .
FILTER( isBlank( ?object ) )
}
and get the results:
#prefix : <http://example.org/> .
:Alice
:likes :Bill ;
:likes [ :likes [ :named "Daphne"
] ;
:named "Carl"
] ;
:named "Alice" .
That's not a complete description of course, because it's only following :likes out from :Alice, not arbitrary predicates. But it does get the blank nodes named "Carl" and "Daphne", which is a start.
The larger issue in Sesame
It looks like you're going to have to do something like what's described above, and possibly with multiple searches, or you're going to have to modify Sesame. The alternative to writing some creative SPARQL is to change the way that Sesame implements describe queries. Some endpoints make this relatively easy, but Sesame doesn't seem to be one of them. There's a mailing list thread from 2011, Custom SPARQL DESCRIBE Implementation, that seems addressed at this same problem.
Roberto García asks:
I'm trying to customise the behaviour of SPARQL DESCRIBE queries.
I'm willing to get something similar to CBD (i.e. all properties and
values for the described resource plus all properties and values for
the blank nodes connected to it).
I have tried to reproduce a similar behaviour using a CONSTRUCT query
but the performance is not good and the query gets quite complex if I
try to consider long chains of properties pointing to blank nodes
starting from the described resource.
Jeen Broekstra replies:
The implementation of DESCRIBE in Sesame is hardcoded in the query
parser. It can only be changed by adapting the parser itself, and even
then it will be tricky, as the query model has no easy way to express it
either: it needs an extension of the algebra.
> If this is not possible, any advice about how to implement it using CONSTRUCT
queries?
I'm not sure it's technically possible to do this in a single query.
CBDs are recursive in nature, and while SPARQL does have some support
for recursivity (property chains), the problem is that you have to do an
intermediate check in every step of the property chain to see if the
bound value is a blank node or not. This is not something that SPARQL
supports out of the box: property chains are defined to have only length
of the path as the stop condition.
Perhaps something is possible using a convoluted combination of
subqueries, unions and optionals, but I doubt it.
I think the best workaround is instead to use the standard DESCRIBE
format that Sesame supports, and for each blank node value in that
result do a separate consecutive query. In other words: you solve it by
hand.
The only other option is to log a feature request for support of CBDs in
Sesame. I can't give any guarantees about if/when that will be followed
up on though.