Re: Comments on Draft

On 3/17/2015 11:42, Karen Coyle wrote:
>
>> http://w3c.github.io/data-shapes/shacl/#global-constraints
>>
>> I hope this was clarified by "Additional constraints can either be
>> stated globally ..." further down.
>
> Well, I didn't connect it. Perhaps:
>
> "Graph structures *can* be captured as shapes..." The "some" there 
> gives me a different impression - it makes it sound like some graphs 
> are not "shape-able" rather than that one can decide to treat them as 
> shapes or not. (This could just be me, so I'd like to hear other 
> impressions.)

In fact many structures can not be captured as shapes, so I believe 
"some" is appropriate wording. In the context of SHACL, the term Shape 
is only about a group of constraints that has the same focus node. 
Constraints such as counting the number of triples, or making sure that 
there is at most one distinct subject do not fit into that category. 
Also, Shapes are evaluated differently - they usually have some mapping 
mechanism that associates them with specific nodes.

>
>>
>>>
>>> "be associated with shapes, using SPARQL and similar executable
>>> languages."  End sentence where comma is now,
>>
>> That would leave the sentence unfinished.
>
> I don't think so. It would be:
>   "Additional constraints can either be stated globally or be 
> associated with shapes."
>
> That is a bit terse, but I think it is complete. But now I think the 
> comma tricked me, and what you really meant was :
>
> "Additional constraints can either be stated globally or be associated 
> with shapes using SPARQL and similar executable languages." And this 
> now makes sense as is although I would change the "and" to "or." But 
> that discussion is below....

Ok, comma removed.

>
>>
>>> or replace clause simply with ", using executable languages." SPARQL
>>> is not, as I understand it, required so someone could implement SHACL
>>> without it. (Maybe it's the "and" there that is a problem.)
>>
>> Let's be clear that we are not mixing
>> - the implementation language of the engine
>> - the selected executable language in an RDF graph (sh:sparql,
>> shx:javaScript etc).
>>
>> The "and" was put there intentionally, because the current design
>> suggests that every well-formed native SHACL constraint must have a
>> sh:sparql. It may however also have other properties for other
>> languages, supporting engines implemented in JavaScript. The "and"
>> signals that SPARQL is used as fall-back so that all published SHACL
>> files can be interchanged on at least one standardized platform.
>
> So here's the point where I think we need clarity:
>
> "every well-formed native SHACL constraint must have a sh:sparql."
>
> and what was really meant when the f2f resolved:
>
> "RESOLUTION: Define semantics using SPARQL as much as possible"
>
> First, there is that "as much as possible" which could mean that 
> "every well-formed native SHACL constraint "MAY" or "SHOULD" have a 
> sh:sparql, but not "MUST".

The "as much as possible" is only about the core templates (e.g. 
sh:minCount). It is still an open issue whether sh:OrConstraint and 
sh:valueShape should be represented in SPARQL or whether we should 
rather rely on a "hard-coded" implementation as part of the engine. The 
current draft has them in SPARQL, using a helper function sh:hasShape, 
but this may change and we revert to definitions as part of the 
Operations chapter.

The "every well-formed" is about the constraints that our users will 
write. On the current proposal is that for those there must (also) be a 
sh:sparql. It was Peter who actually proposed that - my original 
proposal was a bit more relaxed. The group has not yet decided one way 
or another, but I have not heard opposition to Peter's view point and I 
agree it certainly makes a lot of sense unless we want to cause the 
SHACL community to fragment.

>
> I admit that I have assumed that SPARQL is appropriate and convenient, 
> but I haven't gotten the impression that it would not be valid to 
> define a SHACL constraint using a different executable language and 
> not also (or first) using SPARQL. We should clarify is SPARQL is 
> mandatory to define SHACL constraints, with any other executable 
> languages being only IN ADDITION TO it. To me, that would go a long 
> way toward my understanding of the spec.

This was my intention. If you have additional suggestions on how to make 
this fact clearer, I'd like to hear them.

>
> Then, it looks like there may be different interpretations of "Define 
> semantics." I don't want to even try to describe what those different 
> interpretations could be, since there are folks on this list who have 
> a much more sophisticated concept of "semantics" than I do. But again 
> it I think would be helpful if we made sure we had a shared definition.
>
>
>>
>>>
>>> *** document ***
>>> 1. Introduction, second paragraph
>>> For more complex use cases, SHACL also includes facilities to define
>>> almost arbitrary restrictions, expressed in SPARQL and, possibly,
>>> other languages such as JavaScript. SHACL includes macro facilities
>>> for the creation of new high-level vocabulary terms based on languages
>>> like SPARQL. These advanced topics are covered from section 7 onwards.
>>>
>>> *** kc comments ***
>>>
>>> s/"almost arbitrary restrictions"/"needed restrictions"
>>
>> I replaced "almost arbitrary restrictions" with "other restrictions" for
>> now.
>>
>>> s/"expressed in SPARQL and, possibly, other languages such as
>>> JavaScript"/"expressed in an executable language"
>>
>> I do not see why we should downplay the SPARQL ability. This is a major
>> attraction to many users. No other language is currently on the table
>> for consideration. I have for now rephrased the sentence to
>>
>> "For more complex use cases, SHACL also includes facilities to express
>> other restrictions in an executable language such as SPARQL and,
>> possibly, other languages such as JavaScript."
>
> This gets to the heart of the matter. I don't think I am downplaying 
> the SPARQL ability -- it will be quite evident in the reading of the 
> document. What I find is that the document is overplaying SPARQL. The 
> use of "and possibly" describes the use of other executables as less 
> than likely. I know that some members of the group do consider the use 
> of anything but SPARQL to be unlikely, but others have stated cases 
> for other languages in their perceived implementations. I think it is 
> important that the language of the document not show prejudice against 
> implementation that are not in SPARQL. If we agree that the standard 
> should be open to other implementation languages, then the "and, 
> possibly" contradicts that.

I am still not sure that we talk about the same things.

a) Some people want to implement SHACL *engines* that are not using 
SPARQL. Examples include the IBM use case where the engine would be 
written in JavaScript, and the ShEx folks who have their own 
implementations. But these are only worried about the core templates 
(e.g. sh:minCount) - they would simply ignore sh:sparql as they only 
advertise support for the SHACL Core Profile. Here the role of SPARQL is 
only to serve as formal specification.

b) Other people want to use other languages than SPARQL as native 
executable for the *constraint definitions* in their RDF files. I 
believe myself that something like shx:javaScript will emerge in the 
future. Jose stated that he would prefer some sub-set of SPARQL or XPath 
instead of full SPARQL.

These are very different discussions. Only in the latter case, we 
currently show a bias towards SPARQL, because sh:sparql is mandatory 
even if shx:javaScript is present, and furthermore SPARQL is the only 
native executable language in the current draft.

>
>
>>
>>>
>>> "SPARQL is the only built-in execution language in SHACL, but other
>>> languages may be supported future versions or by third parties." I've
>>> already commented on this, but I will suggest:
>>> "SHACL constraints are defined in this document as SPARQL queries, but
>>> any other executable language may be used that yields the same result."
>>
>> Already discussed.
>
> The trouble I am having is with the meaning of "built-in." I get a 
> cognitive dissonance between "built-in" and a written specification or 
> a Shapes Constraint Language. (This is one of those "what is the 
> subject of which we speak" moments.) How about using something closer 
> to: The SHACL specification provides SPARQL definitions* for each of 
> its constraints, but any other executable language may be used that 
> yields the same result."

I was talking about b) from above. I have changed it to the following to 
avoid the term built-in:

"This version of SHACL defines SPARQL as the only execution language, 
but other languages may be supported in future versions or by other 
communities."

>
>
> OK, although I'm still curious as to how we will define "profiles." 
> This is because it's a bit of a flash point for DCMI, which has done 
> considerable work on what it calls "application profiles" -- so I'll 
> be looking for that.

The term profile is quite overloaded, so I am sure it'll not match the 
term used by DCMI. We can of course define a better term if someone has 
proposals.

>
>>
>>>
>>> *** ***
>>> That's as far as I got, although I do have one high-level suggestion,
>>> which is to make this change:
>>>
>>> s/B. SPARQL Definitions of the Built-in Templates/B. SHACL Templates
>>> with SPARQL Definitions.
>>
>> Currently all built-in SHACL Templates have SPARQL definitions, so I
>> think the current heading is appropriate.
>
> First, there's the "built-in" again, and I really do want to get that 
> out of the document. 

Ok, I have removed "built-in" from everywhere.

> Then, I think we want to emphasize that these are SHACL templates, so 
> we should call them "SHACL Templates." It could be either:
>
> B. SPARQL Definitions of SHACL Templates

Ok, I have used that. Could also be "SHACL Core Templates" yet even the 
term "Core" is questionable and may be changed in the near future.

Here is the latest revision:

https://github.com/w3c/data-shapes/commit/ff365e0cfa17408b30d2ba449daffd764b74e06e

Thanks
Holger

Received on Tuesday, 17 March 2015 02:44:19 UTC