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

Both "shape" and "shapeClass" are used, and I don't see a contradiction.

A keyword "SHACL" would be useful if SHACL code is embedded into Turtle 
files, but wouldn't carry the right semantics (and wouldn't allow to 
distinguish between shapes and shapes+classes as the current draft 
does). If we are required to add a keyword "SHACL" then clearly ShExC 
needs to introduce a keyword "ShEx", too. If Eric states that the term 
"shape" overlaps then it would need to be deleted from both languages.

Holger


On 27/05/2017 2:52, Sandro Hawke wrote:
> Holger also amended the keyword from SHACL to "shapeClass" or maybe 
> "shape". (His email seems to say one while the spec says the other: 
> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2017May/0041.html 
> )
>
>       -- Sandro
>
> On 05/26/2017 11:32 AM, Eric Prud'hommeaux wrote:
>> In today's meeting, ShEx CG discussed and approved Sandro's proposal,
>> including Holger's amendment to change ";" to ".".
>> <https://www.w3.org/mid/7d237518-a561-7c86-d7cb-bbfe744055b0@w3.org>
>>
>>
>> * HODGES Jr, John <jack.hodges@siemens.com> [2017-05-25 20:15+0000]
>>> It is a good idea.
>>>
>>> Regards,
>>> Jack Hodges, Ph.D.
>>>
>>> Siemens Corporation
>>> CT RDA NEC WOS-US
>>> 1936 University, Suite 320
>>> Berkeley, CA 94704-1074, USA
>>>
>>> Mobil: +1 510 289-2982
>>> mailto:jack.hodges@siemens.com
>>>
>>> From: Irene Polikoff [mailto:irene@topquadrant.com]
>>> Sent: Thursday, May 25, 2017 1:13 PM
>>> To: Sandro Hawke
>>> Cc: Eric Prud'hommeaux; HODGES Jr, John (CT RDA NEC WOS-US); Holger 
>>> Knublauch; public-data-shapes-wg@w3.org
>>> Subject: Re: SHACL Compact Syntax, was Re: Fwd: Transition Request: 
>>> 3 FPWGNOTE documents
>>>
>>> I think it is a good idea.
>>>
>>> On May 25, 2017, at 4:09 PM, Sandro Hawke 
>>> <sandro@w3.org<mailto:sandro@w3.org>> 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><http://example.com/ns>
>>>
>>>
>>>
>>> IMPORTS 
>>> <http://example.com/person-ontology><http://example.com/person-ontology>
>>>
>>>
>>>
>>> PREFIX ex: <http://example.com/ns#><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><mailto:eric@w3.org> wrote:
>>>
>>>
>>>
>>> * HODGES Jr, John 
>>> <jack.hodges@siemens.com><mailto: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><mailto: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><mailto: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><mailto: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<mailto: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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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
>

Received on Friday, 26 May 2017 22:19:43 UTC