Re: Turtle file

Hi Arthur,

I believe you are making valid observations but I disagree with your 
conclusions. In fact I believe all issues that you mention can be 
(easily) addressed over the coming months, and we should definitely 
release the SHACL RDF file, and use SHACL to represent its own 
vocabulary (we could also publish a trimmed down RDFS-only version, but 
that's an orthogonal question).

On 9/25/2015 7:33, Arthur Ryman wrote:
> Peter,
>
> Yep.
>
> My concern with that file is that it contains many terms not discussed
> or reviewed by the WG.

Yes, but we simply have not spent time yet (as a group) to investigate 
the vocabulary file at all.

>   I feel that it reflects how Holger implemented his processor.

Yes and no. This is not just "my" processor but is an application of 
standard SHACL features, i.e. its shapes and SPARQL extension mechanism. 
There is nothing TopBraid-specific in this file, and it shouldn't be.

>   For example, he decided to implement the built-ins as
> templates, which has a certain elegance, but is not required for
> compliance AFAIK.

Correct, this aspect is not relevant for the Core only, but if we don't 
implement constraints as templates then many aspects of the extension 
mechanism will not work. For example, we need to define classes such as 
sh:PropertyConstraint so that extensions can hook in their additional 
constraint types. Another example are violation IDs that I have just raised

     https://www.w3.org/2014/data-shapes/track/issues/96

>   Furthermore, by including such terms as
> sh:AbstractAllowedValuesPropertyConstraint are we requiring
> implementers to support this design, i.e. to understand what it means
> to subclass from this template class?

Only implementation that support the extension mechanism would have to 
support those. No need to worry about this from a Core perspective. 
However, even the implementations that use the extension mechanism will 
get all this "for free" because the SHACL vocabulary already provides 
the declarative infrastructure and everything will work "automatically" 
with minimal implementation work. If an engine supports the extension 
mechanism, then it will also automatically support the whole Core language.

This is a major selling point of SHACL, both for implementers and users 
alike, because we can point them at a consistent language design where 
everything is handled uniformly.

Moving forward, this topic may be best handled by a Task Force 
assembling interested parties that have implementation experience. This 
way we could have some work done in parallel without spending full WG 
resources and precious meeting time. We could then present a worked out 
file to the group.

Holger


> I'd prefer to see this type of
> detail removed from the core vocabulary and moved to an
> implementation-specific vocabulary that was not normative.
>
> The current vocabulary omits refs:isDefinedBy triples which are
> normally how terms are linked to the vocabulary.
>
> -- Arthur
>
> On Thu, Sep 24, 2015 at 5:15 PM, Peter F. Patel-Schneider
> <pfpschneider@gmail.com> wrote:
>> I think that
>> https://github.com/w3c/data-shapes/blob/56429ef268a14e29586244ab944b310ea84cbf46/shacl/shacl.shacl.ttl
>> Has the document I was looking for.
>>
>> peter
>>
>>
>>
>>
>> On 09/24/2015 01:37 PM, Arthur Ryman wrote:
>>> Peter,
>>>
>>> You can look at the commit history for the branch.[1] I saw a commit
>>> described as "Latest TTL File" [2].
>>>
>>> [1] https://github.com/w3c/data-shapes/commits/gh-pages/shacl
>>> [2] https://github.com/w3c/data-shapes/commit/56429ef268a14e29586244ab944b310ea84cbf46#diff-dd3652a97f249d2a18a436bd4fac69c5
>>>
>>> -- Arthur
>>>
>>> On Thu, Sep 24, 2015 at 3:07 PM, Peter F. Patel-Schneider
>>> <pfpschneider@gmail.com> wrote:
>>>> How does one find the Turtle file now?
>>>>
>>>> peter
>>>>

Received on Tuesday, 29 September 2015 01:20:19 UTC