- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 11 Mar 2016 14:36:04 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
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