LDP and quads - what should I expect at the SPARQL side?


#1

Hi all!

At Kingsley’s request, I am moving this conversation into a public forum.

I want to understand the behaviour of Virtuoso’s LDP implementation with respect to PUT/POST of Quads. In particular, given that the URI of the LDP Resource is used as the named graph in the SPARQL endpoint (which is gorgeous, by the way! I love that!!!) it isn’t clear to me what happens if I provide a named graph inside of the Resource (or Container) itself. Which one takes precedence at the SPARQL side? What is the expected behaviour? What options do I have to control the behaviour?

Looking forward to comments!

Mark


#2

Hi Mark,

How exactly is the named graph being specified inside of the Resource (or Container) itself, as this is unclear to me, thus can you provide a use case example ?

Best Regards
Hugh Williams
OpenLink Software


#3

Hi Mark,

Thanks for the post!

When referring to quads which of the following matches your interpretation?

## here <> denotes an RDF data source that Virtuoso maps 
## to a Named Graph implicitly 
prefix : <#> . 

:this :relatedTo :that . 

or

## here <> denotes an RDF data source that Virtuoso maps 
## to a Named Graph explicitly via NQuads
prefix : <#> . 

:this :relatedTo :that  <> . 

#4

Using shorthand:

POST -H "Slug: Result5" -d "<#this> <#relatedTo> <#that> <#nanoPubMetadata1>" http://my.server/LDP/data/


#5

NQuads is only supported via our Bulk Loader at the current time.
The only time you have potential for Graph IRI collision is if you sponge an RDF document in one operation and then repeat a similar operation using curl targeting the same doc i.e., doc is identified by same URI.

Graph Security and Attribute-based Access Controls (ABAC) are features in the commercial edition that protect named graphs via rules etc…

I hope this clarifies matters?


#6

Yes, that’s clear. Thanks!