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

We probably lack detailed SPARQL expertise in this WG, and the WG is 
very short in numbers anyway. How is this handled in other WGs? Wasn't 
there a concept of liaison between groups, or some mechanism to invite 
external contributions? I am not a magician, and Andy has many other 
things on his plate too. We'll get to it eventually, but promising a 
time line is not feasible. Even if it doesn't look so, we all have day jobs.

Holger


On 11/03/2016 16:03, Peter F. Patel-Schneider wrote:
> 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:09:48 UTC