Re: SHACL Compact Syntax, was Re: Fwd: Transition Request: 3 FPWGNOTE documents

On 26/05/2017 8:13, Holger Knublauch wrote:
> Ok, so Sandro has two interesting points.
>
> 1) Add a keyword before a shape definition. If that keyword were 
> "SHACL" then I think ShEx should introduce a similar keyword. But I 
> guess a SHACL keyword would make much more sense for the Trig idea 
> below, so I'd go with two keywords: "shape" or "class" (ignoring 
> case), where the latter would support the definition of an rdfs:Class 
> that is also a sh:NodeShape. This way the extra keyword at least 
> fulfills another purpose than being the differentiator. Unless I hear 
> otherwise, I will apply this change. Could Dimitris and Simon (and 
> others who have objected to the current WG Note draft) give me 
> feedback on whether they would still be against publishing SHACL 
> Compact before the WG expires? The obvious fallback is to use the 
> SHACL Community Group.

This is now implemented, test cases updated etc:

     http://w3c.github.io/data-shapes/shacl-compact-syntax/

I went with the keyword "shapeClass" instead of "class" to clarify what 
this means and also to distinguish from the "class" keyword that was 
already used to mean sh:class. So the new keywords "shape" and 
"shapeClass" guarantee that SHACL-CS and ShExC files will never overlap 
(except for the empty file I believe), down to grammar parsing level.

Awaiting further instructions.

Holger


>
> 2) Make SHACL a plugin to Trig or Turtle. Yes, excellent point. See 
> [1]. I think this would best be handled by TTL/TriG themselves, also 
> to include things like OWL Manchester Syntax or ShExC. How are the 
> chances that such a general mechanism could be added to those 
> standards so that we merely define a plugin? In either case, the 
> compact syntax would stand alone, too.
>
> Cheers,
> Holger
>
> [1] 
> http://composing-the-semantic-web.blogspot.com.au/2006/11/plug-in-mechanism-for-n3turtle.html
>
> On 26/05/2017 6:09, Sandro Hawke wrote:
>> On 05/25/2017 01:42 PM, Irene Polikoff wrote:
>>> The mandate to produce the compact syntax is separate from the decision to use ShEx as input or to align with ShEx. The mandate was at a level of a requirement - the WG should produce it.
>>>
>>> The desire to re-use ShEx in this undertaking was understandable, but it is at the next level, which is what would be the best way to satisfy the requirement in the charter.
>>>
>>> I believe the original alignment plan assumed some changes in ShEx so that the syntax could work with SHACL - just like all the other inputs to the WG were changed in order to create SHACL. Without such changes in ShEx, I do not see how ShEx syntax could become a compact syntax for SHACL.
>>>
>>> As things stand now, I agree that it is easy to show a compatible subset, but, as you say, it would be very limited. Basically, only ShEx shapes that do not use disjunctions (or anything with any level of complexity) will be compatible and they will have to explicitly state cardinalities. This small subset would not be enough to satisfy even some very basic use cases. Given the limited nature of supported use cases, the RDF syntax for such shapes would be relatively compact as well. So, it is hard to see any value in this.
>>>
>>> Further, the ShEx syntax would need to be extended to support targets, imports, address differences in the treatment of CLOSED, etc., etc.
>>>
>>> Given this, I think the WG did the only thing possible - used ShEx as an input that represents what type of compact syntax could satisfy the requirement.
>>>
>>> I also agree with Tom Baker that we need to make sure that it is clear to users that something is SHACL shape and not a ShEx shape. In fact, I brought this up in a meeting a couple of months ago when the compact syntax was discussed. There were a number of differences already, but I thought we needed something more “pervasive”. Holger’s recent change of the separator accomplishes this.
>>
>> I think Holger's change of ';' to '.' is good, but I can imagine it 
>> could easily be mistaken for an error, and it's impossible to google for.
>>
>> Maybe we can also add a keyword?  Like:
>>
>> BASE<http://example.com/ns>
>>
>> IMPORTS<http://example.com/person-ontology>
>>
>> PREFIX ex:<http://example.com/ns#>
>>
>> SHACL ex:PersonShape -> ex:Person {
>>  closed=true ignoredProperties=[rdf:type] .
>>
>>  ex:ssn       xsd:string [0..1] pattern="^\\d{3}-\\d{2}-\\d{4}$" .
>>  ex:worksFor  IRI ex:Company [0..*] .
>>  ex:address   BlankNode [0..1] {
>>   ex:city xsd:string [1..1] .
>>   ex:postalCode xsd:integer|xsd:string [1..1] maxLength=5 .
>>  } .
>> }
>>
>> That keyword could also be SHAPE or CHECK or CONSTRAINT or something 
>> else.
>>
>> I think I would also make the syntax be TRIG *plus* this. So, start 
>> with trig parser, then add a check for the SHACL keyword, followed by 
>> a shape expression like this.
>>
>> That way you can mix your data and your constraints. You can even mix 
>> your constraints written in shacl-turtle with your compact syntax 
>> stuff like this.
>>
>> Just a thought.
>>
>> -- Sandro
>>
>>
>>
>>
>>>
>>>
>>>> On May 25, 2017, at 12:24 PM, Eric Prud'hommeaux<eric@w3.org>  wrote:
>>>>
>>>> * HODGES Jr, John<jack.hodges@siemens.com>  [2017-05-25 00:44+0000]
>>>>> If there is a mandate to produce a compact syntax and there is no way to make the ShEx camp happy (or to get them to improve it), then perhaps this WG should push forward.
>>>> The original plan in the data-shapes WG was to align ShEx and SHACL so that the ShEx syntax could be applied to SHACL. The WG gave up on that in December due to lack of time. It's easy to show a compatible subset for unqiue, top-level properties, but it only applies to simple conjunctions.
>>>>
>>>>
>>>>> The examples I have seen show that the approaches have different semantics.
>>>> Yeah, this is the fundamental issue.
>>>>
>>>>
>>>>> Jack
>>>>>
>>>>> Sent from my Siemens iPhone
>>>>>
>>>>> On May 24, 2017, at 4:21 PM, Holger Knublauch <holger@topquadrant.com<mailto:holger@topquadrant.com>> wrote:
>>>>>
>>>>> FWIW I have made a simple switch that will make accidental clashes between the two compact syntaxes very unlikely: Instead of ending lines with ';' we now use '.' (like SPARQL/Turtle).
>>>>>
>>>>> I wouldn't mind holding off the release of SHACL Compact Syntax and vote again next week. I do believe however that we could just as well go ahead as planned. The document had been visible to the public for quite a while now, without such feedback. I had also sent direct emails to the people in the acknowledgements section, without getting any response, so I assumed it was OK. And any WG Note is just a starting point, with the explicit goal of serving as input to future standardization efforts.
>>>>>
>>>>> On the general topic I can only reiterate that the Shapes WG had made several resolutions that a Compact Syntax is produced and that it should look like ShExC. The explicit assumption was that this would be a deliverable by the WG, I believe it was even assigned to someone from the ShEx "camp". We are merely executing on those resolutions although I would have preferred if someone else had worked on them.
>>>>>
>>>>> Given the unfortunate politics around this WG, we cannot make everyone happy.
>>>>>
>>>>> Holger
>>>>>
>>>>>
>>>>> On 25/05/2017 4:17, Sandro Hawke wrote:
>>>>> Tom's email, to which Irene is replying, was send to a W3C Member Confidential mailing list (chairs@w3.org<mailto:chairs@w3.org>).  She accidentally included it in her reply, perhaps not knowing the list's confidentiality (which is not obvious).   Here's my to reply to that list, which bears on this this group:
>>>>>
>>>>> My sincere apologies, Tom.  You mentioned this concern to me earlier, and then I completely forgot about it in the flurry of documents.  That was a serious error on my part.
>>>>>
>>>>> I agree, it's a very bad architectural practice to design languages such that a non-trivial document could be syntactically valid in multiple languages while having different semantics.   We pretty much only see this in a few notoriously bad situations, like "1/2/2017" being either 2017-01-02 or 2017-02-01, depending on the locale.
>>>>>
>>>>> I suggest the Data Shapes Working Group withdraw its decision to publish this (or the Director not approve it), and instead delegate to an expected new SHACL CG to figure out a way to make the syntax disjoint from ShExC in at least the cases where the semantics are distinct, [then] publish it as a CG Report, much like ShExC, instead of a WG Note (since the WG will presumably have expired by then).
>>>>>
>>>>> Does that sound like a reasonably path forward?
>>>>>
>>>>> I guess another option would be to make a trivial change to the syntax (before next week) to make it disjoint, but I believe the community would be far better served by having the syntax be the same in places where the semantics are the same.  If that's possible, it seems worthwhile to take the time in a CG to figure that out in concert with ShEx folks.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>>       -- Sandro
>>>>>
>>>>>
>>>>> On 05/24/2017 11:57 AM, Irene Polikoff wrote:
>>>>> I really do not think ShEx has a “copywrite" on an idea of a compact syntax. Its syntax itself was itself influenced by many different syntaxes/previous works, I am sure.
>>>>>
>>>>> Further, the syntaxes are not identical. They are similar. For example, SHACL has target declarations and it is supported in the syntax. The way cardinalities are expressed is different.
>>>>>
>>>>> I guess one option would be to modify the syntax to be even less similar. But I can’t think what could be done to make it significantly more different - because the information it is trying to express is very similar and it is expressed in an obvious way as a “property”, then a list of constraints for the values such as the data type, cardinality, etc. There is nothing novel or special in this format.
>>>>>
>>>>> I suppose one could change delimiters. However, many delimiters are quite standard and making them into something else would be very peculiar e.g., the use of ‘|” for ‘or’; the use of “;”  as a separator. These are used by many-many languages. With this, I am not sure what changes would be sufficient to ensure that SHACL and ShEx compact syntax can’t be confused. Should SHACL WG members object to the ShEx CG use of the words ‘shape’, ‘node shape’, etc.? Because this will be confusing to potential users - when they hear or see shape, they wouldn’t know which one.
>>>>>
>>>>> Overall, this sounds like an attempt to prevent SHACL from having a compact syntax so that for those who want a compact syntax, ShEx will be an only option. This is not good for the community and, to me, sounds like a desire to block progress and deprive users of SHACL of features. No one should have a right to do this, especially not on the open web.
>>>>>
>>>>>
>>>>> Begin forwarded message:
>>>>>
>>>>> From: Tom Baker <tom@tombaker.org<mailto:tom@tombaker.org>>
>>>>> Subject: Re: Transition Request: 3 FPWGNOTE documents
>>>>> Date: May 24, 2017 at 11:05:47 AM EDT
>>>>> ...
>>>>>
>>>>>
>>>>> This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation
>>>> -- 
>>>> -ericP
>>>>
>>>> office: +1.617.599.3509
>>>> mobile: +33.6.80.80.35.59
>>>>
>>>> (eric@w3.org)
>>>> Feel free to forward this message to any list for any purpose other than
>>>> email address distribution.
>>>>
>>>> There are subtle nuances encoded in font variation and clever layout
>>>> which can only be seen by printing this message on high-clay paper.
>>>>
>>
>