Re: WG meeting 2017-04-05

Hi Sandro,

I have now integrated the TTL into a new Appendix C, using the paragraph 
you suggest below as a placeholder. Let's discuss what to do next in the 
upcoming meeting. I am unsure what to do specifically about the Errata 
page, i.e. where to put it, and also where the future TTL file should 
evolve. I believe that it is quite possible that the TTL file has flaws 
because it is very hard to get this 100% tested in such a short time 
frame (assuming Tim didn't expect us to delay the release for a month 
just for this TTL). So it would probably be best to be promise a bit 
less along the lines of "the textual definitions are normative; if the 
TTL file diverges then it's a bug in the TTL file and you should look at 
XY for an update.".

BTW I didn't even try to formalize the syntax rules for SHACL-SPARQL. 
There would be some easy ones, but many of these rules are just 
impossible to express because they need to analyze the structure of the 
SPARQL queries. This is another reason why I believe that in addition to 
the given SHACL-SHACL file, 3rd parties will produce additional 
checkers. These could also check for best-practices, specific 
sub-dialects of SHACL etc. There won't ever be a single-size-fits-all 
TTL file.

Holger


On 5/04/2017 3:32, Sandro Hawke wrote:
> On 04/04/2017 09:50 AM, Irene Polikoff wrote:
>> As for the appendix with the SHACL-for-SHACL, my understanding was that it should be “normative” - whatever this means. For example, does it mean that we should say “Shapes graph that doesn’t pass validation against SHACL-for-SHACL is ill formed”?
>>
>
> That's a really tricky question.   I thought about it a lot yesterday.
>
> I might do it more like:
>
>     This shapes graph is intended to enforce many of the syntactic
>     constraints in this specification.  As such, it can be understood
>     as a machine-readable version of a subset of those constraints,
>     and should be understood as normative.  If differences are found
>     between the constraints expressed here and elsewhere in this
>     specification, that indicates an error in this specification. 
>     Please see the _errata_ page_ for an enumeration and analysis of
>     possible errors that have been reported.   Since the text of this
>     specification cannot be updated after publication, consider using
>     an alternative version which may have less review but can be
>     maintained, such as _link_to_some_maintainable_version.
>
> Does that make sense?
>
> Note that the use of an "Errata" page is required in W3C 
> Recommendations.   See for example 
> https://www.w3.org/TR/2013/REC-sparql11-query-20130321/
>
> These days, I'd probably have it redirect to a github query for issues 
> with a particular tag.
>
> The 'maintained' version can be formally managed by a Community Group 
> after the WG is done, I guess.
>
>       -- Sandro
>