Re: Shapes/ShEx or the worrying issue of yet another syntax and lack of validated vision.

Dear All,

First thank you for the replies, and the willingness to openly discuss this. I was not realising that this is still at the pre workgroup stage.
Giving me a lot more hope that we are going to get a good consensus standard.

On 15 Jul 2014, at 18:29, Sandro Hawke <sandro@w3.org> wrote:

> On 07/15/2014 11:35 AM, Jerven Tjalling Bolleman wrote:
>> Dear All, 
>> 
>> Let me apologize in advance for the rude tone of this e-mail. 
>> 
> 
> :-)    I for one appreciate your passion on this.     I'm not the right person to reply to all of this, but let me just make a few points.
> 
>> I am looking at the current work/direction of the work-group and am really worried. 
>> 
>> Issues 
>> 
>> First off all you decided not to focus on the problem of validating data in RDF but on a solution called shapes. I think you need to go back and collect what validation should do first instead of what the solution looks like. Because I don't think ShEx/Shapes does enough. 
>> 
>> Secondly I have the feeling that the work-group is confounding the issue of syntax and user interfaces as well as ignoring a lot of engineering effort out there in the world. 
>> 
>> Concerns 
>> 
>> My current concerns are mostly based on this document http://www.w3.org/2013/ShEx/Primer. 
>> 
>> Concern 1. 
>> 
>> First of all its yet another syntax with strange variations on turtle. 
>> 
>> <IssueShape> { 
>>     ex:state (ex:unassigned ex:assigned), 
>>     ex:reportedBy @<UserShape>, 
>>     ex:reportedOn xsd:dateTime, 
>>     ( ex:reproducedBy @<EmployeeShape>, 
>>       ex:reproducedOn xsd:dateTime      )?, 
>>     ex:related @<IssueShape>* 
>> } 
>> 
>> Why the brackets and @ for some kind of pointers? why not make nice and simple turtle and do this? 
>> 
>> 
>> :IssueShape 
>>     ex:state (ex:unassigned ex:assigned) ;
> 
> Here you've adopted the Turtle syntax, but taken up a different semantics, which is a pretty big problem.  For example, if the rdfs:domain of ex:state is ex:Issue, you've now forced :IssueShape to be an instance of class ex:Issue, which is surely not correct.
> 
> I agree there should be an RDF representation for data shapes, but I think it has to be somewhat more complicated than the example you provide, so the need for a syntax like ShEx is somewhat greater than you suggest.
Fair enough, and I would not mind an evolution of Turtle similar to N3 (or did turtle devolve from N3). What I don’t like is reuse of similar constructs but made quite different in meaning. For example the { use is fine (although not needed I think), even the ? I can live with what I don’t like is the reuse of <> and () for different semantics.
> 
> 
> Minor detail, what you're responding to is a proposed Working Group Charter.  That charter is being drafted mostly by W3C staff member Eric Prud'hommeaux, although I've contributed some text, as have others on and off the W3C staff, based on input from the community, mostly via last year's Workshop and discussion on this list.
> 
> At some point, if this goes forward, there will be a Working Group which can have opinions, be confused, etc, but for now the thing to be trying to correct is the Charter (and maybe the people editing the charter).
Ah sorry from the mailing list name I thought it was a WG, not being familiar with W3C procedures.
> 
> 
> I personally happen to favor less expressive (and thus simpler and more efficient) solutions in this space.  I'm not trying to convince you, but please understand that as often seen in computer science, expressivity is not an unmitigated good, but rather there is a tradeoff.   There's a lot to be said for simple validation.
I agree with the tradeoff issues. Yet as an user/developer I rather have more expressivity I don’t use than being faced with being unable to express my problem/solution.
It makes even less sense when a large target demographic will either be using OWL-DL or SPARQL hand in hand with ShEx. Remember most of us work day to day in turing complete languages and we still get stuff done. 
> 
>> 
>> ShEx -> Should not invent yet another syntax. ShEx should be modeled in RDF and use existing syntaxes.
> 
> So you're not okay with even a syntactic sugar language, what's called a "compact syntax"
>  in the charter?  Something like OWL's Functional Syntax or Manchester Syntax?
I think you have to be very careful here. IMHO OWL definitely ended up having to many syntaxes.
Manchester and RDF syntax had two very good use cases, I can not find my self in the reasons for standardising the functional and owl/xml standards.
> 
> Why was it okay to invent a SPARQL syntax?   We could have expressed queries in RDF itself.
> (You see that kind of thing in SPIN, and also in RIF-in-RDF.)
Having actually hand written queries in SPIN (turtle) to generate SPARQL I want. I am not as opposed to that as you might think ;)
What I feel is the big difference is that SPARQL took the results of 6 years of experimenting with query languages for RDF in the wild and made a very good common ground.
And you can see how things like SERQL influenced SPARQL. I can’t see how things like ICV and SPIN influenced ShEX.
I would also note that since the turtle/sparql alignment sparql only adds to turtle but does not subtract. 
ShEX syntax is incompatible with turtle because it reuses turtle syntax constructs for new incompatible uses.


As a side note it might well be interesting to standardise the SPIN RDF serialisations for SPARQL queries in any case. e.g. as standard for storing SPARQL stored procedures…


> 
>> 
>> Workgroup -> you to quickly discarded the two widely adopted solutions in industry SPIN (SPARQL) and OWL closed worlds on the outcome of a single workshop. 
> 
> You say "the outcome of a single workshop" as if that were a small thing.    The workshop was widely advertised for months as the time and the place for people who cared about this subject to come forward and be a part of figuring this out.    And many people did.    
I was actually aware of the workshop and if you look in your e-mail archive I did ask about when it was going to be held before the date and time was fixed.
Unfortunately, it was not possible to attend for me or finish my position paper.
> 
> Still, the outcome of that workshop is not intended to limit so much as focus.   It showed a direction to go; it didn't pick particular technologies or solutions.      That's for the anticipated Working Group to do.
> 
> The question now is what guidance is to be given to that Working Group.   On this, I mostly hear you saying that the Working Group should define an RDF syntax for shapes, and have a more expressive solution than ShEx.    
> 
> On the first of these, the heart of the charter is this line:
> Syntax and semantics RDF Data Shapes Language: W3C Recommendation(s) defining the language semantics, an RDF syntax and a compact syntax as described in Scope.
> which clearly says "an RDF syntax", which I think is what you want.
> 
> On the expressivity question, it seems clear to me that's left to the WG to decide.
> 
>> Workgroup -> you don't have a good goal document to states what validation needs to do. 
>> 
> 
> That's for the WG to write, the "Use Case and Requirements" document.
> 
>> I hope you will seriously reconsider your chosen direction because it is breaking the first rule of a good standard -> depend on other existing standards. 
>> 
> 
> Honestly, I'd say the first rule of standards is to make something that people will want to use.  :-)
Oh I thought a standard that people don’t want to use is not a standards ;) but fair comment. 
> 
>       -- Sandro (W3C staff, but not assigned to this WG)
> 
>> Regards, 
>> Jerven Bolleman 
>> 
>> 
>> 
>> 
>> 
>> 
> 

-------------------------------------------------------------------
Jerven Bolleman                        Jerven.Bolleman@isb-sib.ch
SIB Swiss Institute of Bioinformatics      Tel: +41 (0)22 379 58 85
CMU, rue Michel Servet 1               Fax: +41 (0)22 379 58 58
1211 Geneve 4,
Switzerland     www.isb-sib.ch - www.uniprot.org
Follow us at https://twitter.com/#!/uniprot
-------------------------------------------------------------------

Received on Wednesday, 16 July 2014 19:52:39 UTC