Re: named graphs and shapes

On Jun 28, 2014 8:25 PM, "Jeremy J Carroll" <jjc@syapse.com> wrote:
>
>
> I am new to this group and area - so please forgive me if I make newbie
mistakes
>
> My understanding of the motivations seems to be a bullseye on some of my
current tasks.
>
> Here is one of my validations tasks.
>
> I have a quad store with several named graphs.
> For sake of tidiness, I impose a rule that each resource is defined in
exactly one of these named graphs, where
> "being defined" means being the subject of an rdf:type triple
>
>
> I validate this with SPARQL something like
>
> ASK {
> GRAPH ?g1 {
>    ?s rdf:type ?t1
> }
> GRAPH ?g2 {
>    ?s rdf:type ?t2
> }
> FILTER ( ?g1 != ?g2 )
> }
>
>
> which must be false

I see this exceeding the current ShEx expressivity by two aspects:

  1 ShEx is currently defined only for graphs, not RDF datasets.

  2 ShEx doesn't compare two terms on the graph.

It was my intention to extend the abstract syntax and the Compact Syntax to
include name graphs. This could happen sooner rather than later if you want
to geek about it with me.

For comparing 2 graph nodes, one can always felt on some semantic action,
but that kicks you out of the interoperability pool. (Actually, once we
have a candidate model for ShEx over named graphs, the semantic actions in
the ShEx demo might suffice.) I'm intrigued, but don't have a proposal at
the ready. I think it's going to take some use cases and horse trading to
figure out the upper bound on the expressivity.

> I get the impression that this is in scope for the goals but not covered
by the submission???

Agreed, at least the number 1 is on my someday pile.

> I have several other named graph constraints that have significant
business value, because I used named graphs to implement multi-tenancy, and
to provide limited visibility from one organization to another: making an
error on these rules could be deeply problematic where private data gets
shared in a dramatically incorrect fashion: thus having validation rules to
check that we are not making such errors is attractive
>
> Jeremy
>
>
>
>
>