On 10/05/16 23:27, Martynas Jusevičius wrote:
Hey,
I know this is a SPARQL question not specific to Jena, but I couldn't
get an answer on public-sparql-dev, so I'll try my luck here:
https://lists.w3.org/Archives/Public/public-sparql-dev/2016AprJun/0010.html
This is a real problem we have, triples end up in wrong graphs when we
split one large graph into multiple per-resource named graphs.
Martynas
It is always risky to say "can't".
You can't in any practical sense and in the general case within a single
standard SPARQL update request.
If you know something about the data, some things become possible.
The only way to match arbitrary length paths is via property paths. If
you know the possible properties to traverse.
(:p1|:p2|...)+
may help. If you know the stopping properties (non-traverals):
^(:not_p1|:not_p2|...)+
and ultimately:
(^:DoesNotExist)+
which follows anything, expensively, grabbing a lot you don't want
making it impractical.
Other ways I can think of looking at:
* Make the OPTIONAL more complicated.
* Find the data, use DESCRIBE to get a model then use GSP to POST it.
* Use a property function to calculate variables to use in the INSERT
INSERT { ?s ?p ?o }
WHERE {
... pattern ...
(?x ?y) my:calcTriples ( ?s ?p ?o )
}
Andy
2016AprJun/0010 ==>
Hey all,
when mapping tabular data to RDF, we end up with multiple resource
descriptions in one graph. The descriptions are rooted in document
resources and can have optional nested bnode paths attached:
<#resource1> a foaf:Document ;
foaf:name "Resource 1" ;
foaf:maker [ a foaf:Person ; foaf:familyName "FamilyName 1" ] .
<#resource2> a foaf:Document ;
foaf:name "Resource 2" . # no bnodes attached to this one
<#resource3> a foaf:Document ;
foaf:name "Resource 3" ;
foaf:maker [ a foaf:Person ; foaf:familyName "FamilyName 3" ] .
As the next thing, we want to store each description in a separate
named graph. Currently we do something like:
DELETE
{
?doc ?docP ?docO .
?docO ?thingP ?thingO .
}
INSERT
{
GRAPH ?graph {
?doc ?docP ?docO .
?docO ?thingP ?thingO .
}
}
WHERE
{
{
SELECT ?doc ?graph
{
?doc a foaf:Document
BIND (UUID() AS ?graph)
}
}
?doc ?docP ?docO .
OPTIONAL {
?docO ?thingP ?thingO .
}
}
This works in simple cases, but breaks down as soon as the bounded
description is "deeper" than the pattern in OPTIONAL.
I was wondering if this can be solved in a general way, for
description with arbitrarily nested blank nodes? And maybe even
possible to get rid of the pattern checking resource type?
Something like INSERT { GRAPH ?graph { DESCRIBE ?doc } } :)
Martynas
graphityhq.com
