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

We already said that the description is not *complete*, but it's a 
start. We can work out the details, eventually. I am not worried about 
this. Implementations exist, so it's possible. But we may need more 
time. Let's put it back into the queue.

Holger


On 11/03/2016 14:12, Peter F. Patel-Schneider wrote:
> 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:36:40 UTC