shaky foundations for SHACL [was Re: ISSUE-68: Updated definition]

This description is not correct.  As I mentioned in the call today,
skolemization changes the results of a query in ways that are not invertable.
 You mentioned the need to change isBlank.  As well, skolemization changes the
result of str.

Pre-binding and sh:hasShape are a huge part of SHACL in the current design.
They have both had problems from the very beginning.  If these problems can't
be fixed then a different approach is going to be needed.


peter


On 03/10/2016 06:04 PM, Holger Knublauch wrote:
[...]
> I have received this input from a colleague. Here is how he would define the
> process:
> 
>     For query Q and data D, let there be a skolemization function SK that maps
>     blank nodes to URIs 
> 
>     SK : RDF Term -> RDF Term
>        SK: blank node => URI distinct from any URI in the data and any other
>     skolemization URI.
>        SK: term => term    otherwise
> 
>     SK is 1-1.
>     Write SKinv for the inverse function of SK which undoes the blank node
>     mapping.
> 
>     Write SK(X) for SK applied to all the RDF terms in X (X can be data, a
>     query or query results).
> 
>     Write Q evaluated on D as Q(D).
> 
>     Write: Q evaluated with ?v= T as Q[?v=T]
> 
>     For pre-binding of variable ?v to RDF term T, the result of evaluating 
> 
>     Q[?v=t](D) = SKinv ( Q[?v=SK(t)](SK(D)) )
> 
>     i.e write SK(t) into Q to give Q1, evaluate Q1 on SK(D), then undo the
>     skolemization.
> 
> 
> This is not complete enough - it is sketch of what we could do and needs
> clearing up to be suitable for the SHACL doc. As it may take a long time to
> come up with a robust definition, we don't want to spend time on it unless it
> is an agreed way forward.
> 
> Let me add that from an implementation point of view, creating a "View" graph
> that replaces certain nodes is not a big issue. One would basically create a
> new logical dataset in which the named graph is substituted with a graph that
> has additional "added" triples and filters out certain "deleted" triples.
> 
> As I said in the call, we can spend any number of resources on this topic,
> depending on how detailed we want to do it. But we seem to be in the middle of
> more important discussions right now, and I personally don't have the time to
> look into all these details. Meanwhile, we'll have to leave the ticket open.
> 
> Holger

Received on Friday, 11 March 2016 04:13:24 UTC