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

I view the shaky foundations of SHACL as a very serious problem and one that
needs to be addressed now.  However I don't see that problem is being resolved
or that the details are being worked out.  I don't even know whether a
resolution is possible, particularly as one has not surfaced already.  The
only advance that I see is that recursion has been taken off the table for
now, getting rid of some things that the foundation needed to support, but
eliminating recursion doesn't seem to have helped much.

So what to do?  I don't understand the current setup enough to fix it, and
each time I try to understand it I see more holes that need to be fixed.

Are we going to have to come up with a different basis?  I think that it may
come to that if the problems can't be worked out soon.  A different basis for
SHACL, even if it is still SPARQL-based, is probably going to require changes
to the metamodel and perhaps even require that many templates be rewritten.

peter




On 03/10/2016 08:36 PM, Holger Knublauch wrote:
> 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 06:03:57 UTC