Re: Comments on Draft

On 3/16/15 7:43 PM, Holger Knublauch wrote:



>> 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).

Here we need others to weigh in. I was at the f2f, and I've got the 
minutes in front of me, and "core" isn't mentioned. If it was implied, I 
missed that.


> 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.

OK, then I think it may be time to open an issue on: is SPARQL mandatory 
for the definition of SHACL constraints (meaning now and in the future). 
Once that's decided, we can go forward.

>
>>
>> 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.

At this point, I prefer to let others weigh in. This could be just my 
misunderstanding of the f2f resolution.


>>
>> 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.

Again, I don't think we've defined a core, so speaking of core templates 
to define a view is a bit premature. This "SHACL Core Profile" that you 
assume that IBM would use, AFAIK, does not exist, and I'll turn to 
Arthur to ask if this is consistent with his view.

>
> 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.

Again, the question of mandatory needs to be resolved. But in general, I 
do find that the draft reads as being ABOUT SPARQL more than it is ABOUT 
SHACL. I would prefer it to be ABOUT SHACL, with SPARQL as a support 
technology. Many of the edits that I have suggested speak to this. It is 
a question of how things are worded.


>
>>
>>
>>>
>>>>
>>>> "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."

"defines" -- SHACL doesn't define SPARQL - SPARQL is being used to 
define SHACL, if anything. This is why I suggested "provides", or you 
could say that SPARQL is used to define the SHACL constraints. And I 
don't know why you say "only" there. That somewhat contradicts the 
second part of the sentence, given that "only" implies exclusion. I'd 
leave that word out.


>
>>
>>
>> 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.
>

I'm less concerned about the term used than how it is defined. I don't 
think we can state that we have "profiles" unless we define what that 
means -- even if we define by example (although I'd prefer clear 
definition).

Thanks again, I'll try to move forward in the document.

kc

>>
>>>
>>>>
>>>> *** ***
>>>> 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
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Tuesday, 17 March 2015 03:18:44 UTC