- From: Sandro Hawke <sandro@w3.org>
- Date: Sat, 19 Jul 2014 14:34:52 -0400
- To: Kendall Clark <kendall@clarkparsia.com>
- CC: Jerven Bolleman <jerven.bolleman@isb-sib.ch>, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, Jose Emilio Labra Gayo <jelabra@gmail.com>, "Dam, Jesse van" <jesse.vandam@wur.nl>, "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
- Message-ID: <53CABA4C.6010501@w3.org>
On 07/18/2014 06:50 PM, Kendall Clark wrote:
>
>
> On Friday, July 18, 2014, Sandro Hawke <sandro@w3.org
> <mailto:sandro@w3.org>> wrote:
>
> On 07/18/2014 06:00 PM, Kendall Clark wrote:
>> Why take out all of them instead of removing the one that's
>> immature? Near as I can tell ShEx is less than a year old. Does
>> W3 Team really think it should be promoted in place of something
>> like SPIN or ICV, which are 5 or 6 years old? That's indefensible.
> I expect these points of consensus, and the the requirements that
> drove them, are what motivated the creation of ShEx.
>
>
> It's in the W3's mission to stand in for vendors?
It's in the W3C's mission to bring the Web to its full potential.
That's pretty broad. If a W3C member doesn't agree with something
being done, the appropriate channels would be the relevant domain leads
(in this case Ralph Swick), the ceo (Jeff Jaffe), the director (TimBL),
or the Advisory Commitee.
> This is a dangerous move because when vendors don't support ShEx, you
> end up with a failed standard.
Vendor adoption is extremely important. As you know, no W3C spec
goes forward without implementations and without addressing public
comments. Of course that doesn't mean every vendor supports every
spec in their market.
> And that's why the Charter was developed as it was, steering away
> from SPIN and ICV.
>
>
> Charter doesn't even mention ICV as prior work.
A charter is not a research paper, where there are obligations to
cite. It's just supposed to be enough to get folks aligned on a task.
Is there something the charter should say about ICV to help guide the WG?
> And I doubt any vendor is going to get behind ShEx, which is an
> untested research project with weird semantics (Z, really?!) and even
> weirder syntax.
I'm not versed in the technologies here -- I'm just trying to help get
some consensus around the charter -- so I can't comment on things being
"weird". The charter asks the group to start from here and turn it
into something that works better, or to pick somewhere else to start
from, if that's what the group wants. Do you have an alternative
proposal for a starting point that you think would start the group in a
better place and that everyone else would be okay with?
> What I'm hearing now is that for whatever reasons, the Workshop
> was surprisingly non-representative of the industry, or perhaps
> was run in a way which corrupted the signal. Maybe several of us
> somehow misunderstood what Evrin was saying, or maybe he
> misunderstood the question being asked. Maybe the SPARQL question
> was framed incorrectly when discussed. Maybe the wrong people
> were at the Workshop. Fortunately, it's not too late to change
> course.
>
>
> This all seems to systematically confuse implementation, syntax, and
> semantics. Non-SPARQL syntax is fine but SPARQL-based implementation
> is the only thing we'll support.
My limited understanding is that some form of compiling-to-SPARQL is a
requirement. One of the deliverables for the group is to show how
that's done. I could tighten up that wording if you want.
> So, with that in mind, would it work to just take out the mentions
> of specific technologies/solutions from the charter?
>
>
> Works for me to drop mention of ShEx. It's a research project.
Consensus at the workshop, as I recall, was that something like ShEx was
needed and nothing sufficient was available. Thus some folks did
research between then and now, so the WG would have somewhere good to
start, instead of having to do a lot of research itself.
-- Sandro
>
> Cheers,
> Kendall
>
>
>
> -- Sandro
>
>
>
>> Cheers,
>> Kendall
>>
>> On Friday, July 18, 2014, Sandro Hawke <sandro@w3.org
>> <javascript:_e(%7B%7D,'cvml','sandro@w3.org');>> wrote:
>>
>> On 07/18/2014 04:40 PM, Jerven Bolleman wrote:
>>> I completely agree with Kendall.
>>>
>>> A standard would look at the similarities between Resource Shapes, ICV and SPIN and see if a common syntax can be achieved.
>>> What seems to be happening instead is that a 4th independent option is being designed.
>>> Which means that the real standard will then need to look into standardising Shex, Resource Shapes, ICV and SPIN.
>>> Giving standard number 5, which is how WG’s become inspiration for XKCD and Dilbert comics…
>>>
>>> ShEX currently reuses practically nothing of the earlier work or existing W3C standards.
>>>
>>> And a lot is being said about usability but no one recalls the sad joke.
>>>
>>> Some people, when confronted with a problem, think
>>> “I know, I'll use regular expressions.” Now they have two problems.
>>>
>>> ASCII art is not a requirement any more.
>>> Saving bits is a goal of compression algorithms.
>>> Code should strive for readability, especially validation code.
>>>
>>> E.g. this SPARQL pseudo style of using
>>> { [] foaf:name xsd:string }
>>> XOR
>>> { [] foaf:givenName xsd:string }
>>>
>>> Is a much better idea than
>>> { foaf:name xsd:string ;
>>> | foaf:givenName xsd:string }
>>> Where we started using the binary OR symbol to mean XOR and that is rather similar to || or the normal OR people are exposed to.
>>>
>>> For the rest I saw the UniProt ShEX example and it is not at all representative for what a database like UniProt really needs.
>>>
>>> Attached to this e-mail is PDF/poster about how SPIN is actually looked at in the UniProt consortium.
>>>
>>> All in all I really encourage the Charter writers to really look at what is out there being used in the semweb world.
>>> And look at standardising that instead of looking to the XML and Regex planets, which we thankfully left behind.
>>
>> Would it work to just take out the mentions of specific
>> technologies/solutions from the charter?
>>
>> (Note that the charter may have changed since you last read it.)
>>
>> -- Sandro
>>
>>
>>> Regards,
>>> Jerven
>>>
>>>
>>> On 18 Jul 2014, at 18:24, Kendall Clark<kendall@clarkparsia.com> wrote:
>>>
>>>> On Fri, Jul 18, 2014 at 12:20 PM, Dimitris Kontokostas<kontokostas@informatik.uni-leipzig.de> wrote:
>>>>
>>>>
>>>>
>>>> Instead of criticizing what ShEx can't do we should all try to see what ShEx should do.
>>>>
>>>> Why? Standards bodies should be about standardizing existing systems. This is one thing the W3C has consistently gotten wrong in the semantic web space: too much speculative research done in the guise of standardization.
>>>>
>>>> I think we all agree that a compact human syntax (with equivalent RDF representation) that covers common validations cases and SPARQL extensions is something we all want.
>>>>
>>>> SPIN, IBM Resource Shapes, and Stardog ICV already provide that. You can't get any more compact human syntax than, say, Manchester OWL syntax for constraints: seehttp://docs.stardog.com/icv for many *real* examples from shipping code.
>>>>
>>>> I too don't like some parts of ShEx but I think it's a good initiative to bootstrap a standard.
>>>>
>>>> That isn't how standardization works best.
>>>>
>>>> I already raised some issues in the mailing list and have a few more from my experience with RDFUnit - but will raise them later since the maintainers are now too busy replying.
>>>>
>>>> Those are all valid, interesting points for ShEx, which is at this point an interesting proof of concept or prototype of an idea. That work should be carried out in an R&D context. W3C Working Groups are not R&D contexts.
>>>>
>>>> Cheers,
>>>> Kendall Clark
>>> -------------------------------------------------------------------
>>> Jerven BollemanJerven.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,
>>> Switzerlandwww.isb-sib.ch <http://www.isb-sib.ch> -www.uniprot.org <http://www.uniprot.org>
>>> Follow us athttps://twitter.com/#!/uniprot <https://twitter.com/#%21/uniprot>
>>> -------------------------------------------------------------------
>>
>
>
>
>
>
>
>
>
>
Received on Saturday, 19 July 2014 18:35:04 UTC