W3C home > Mailing lists > Public > public-sparql-dev@w3.org > April to June 2016

Re: INSERT resource CBDs into separate graphs

From: Martynas Jusevičius <martynas@graphity.org>
Date: Mon, 9 May 2016 15:08:26 +0200
Message-ID: <CAE35VmxiE=5bM5nVeDnkO=iAScp2GstG4D3Ksmg5cGuxby9VUg@mail.gmail.com>
To: public-sparql-dev@w3.org
Was this the wrong list, a badly formulated question, or simply no good answers?

On Tue, Apr 19, 2016 at 12:32 PM, Martynas Jusevičius
<martynas@graphity.org> wrote:
> 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
Received on Monday, 9 May 2016 13:08:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 May 2016 13:08:56 UTC