- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 21 May 2015 12:00:16 +1000
- To: public-data-shapes-wg@w3.org
- Message-ID: <555D3C30.7000009@topquadrant.com>
On 5/21/2015 0:21, Iovka Boneva wrote: > Sorry I didn't have the opportunity to react earlier. > > Sorry I cannot participate to the discussion, still let me share some thoughts. > > If the features currently present in the ShEx syntax are to be added to Holger's > proposal, how can one hope that their semantics would be simpler than the current > ShEx semantics ? I have serious doubts that the same complex concepts would appear > significantly simpler if defined in SPARQL, or in any other formalism. > > Incrementally adding new features to the semantics of the language: that's > what I've been doing for the last month. > > This proposition sounds to me like: let's take the time to re-define the > semantics from scratch, instead of taking the time to understand what is already > there, and adapt it if needed. Hi Iovka, if you meant to say that "what is already there" is your draft, then I guess we could reverse the argument. The semantics are already specified in SPARQL, so why should we start from scratch with abstract syntax and semantics? The additional bonus here is that the SPARQL-based spec is not just a piece of paper but can also be used at runtime, with a generic engine driven by RDF files. In my design, syntax and semantics of SHACL are formalized in a single Turtle file. The HTML document merely provides a human-readable version of it and adds missing details for implementers. This may not be the preferred way that you would personally like to see it specified in. I can only speculate that you may find your own approach cleaner from an academic point of view, and I know you have all spent a lot of time on this topic and I would feel frustrated in such a situation too. But the group decided to "use SPARQL as much as possible", and Arnaud's proposal reflects this resolution. I am confident there are plenty of other ways for you to get your work published and it may be helpful for cross-checking the SPARQL-based spec in the future. It may also be useful to implement matching and graph coverage algorithms, but the focus of this WG is constraint checking. Thanks, Holger > > Best regards, > Iovka > > > Le 20/05/2015 02:14, Arnaud Le Hors a écrit : >> I want to restate the idea/proposal I talked about at the end of the >> call. I know it isn't without challenges but I think there is a >> chance here of getting to something we could all live with. Short of >> that we will have to agree to disagree and fail to produce a common >> solution so, before we reject it, I'd like us to give it serious >> consideration. The idea is as follows: >> >> 1) Strengthen Holger's proposal based on Peter's solid foundation >> 2) Rebase the ShEx proposal as a user-friendly syntax layer on top of >> the above >> >> Arguably 1) could be done by either fixing Holger's draft or turning >> Peter's proposal into a draft and adding what's missing such as >> templates. The latter might lead to something cleaner but the former >> seems a lower hanging fruit. We can discuss. >> >> Doing 2) will certainly lead to identification of specific gaps. We >> can then discuss what to do about each gap: e.g., drop the feature or >> extend the base (possibly beyond what SPARQL alone can do). >> >> We still have issues to resolve such as the entailment regime, the >> relationship between shapes and classes, whether SPARQL is the only >> extension mechanism, etc. But I don't see any of these as impossible >> to solve. >> >> Let's not fight over which approach is better. Let's work together to >> make it work for us all. Yes, it does require willingness to >> compromise in some areas. But that's part of the standard process so >> if you're here I trust that you're ready for that. >> -- >> Arnaud Le Hors - Senior Technical Staff Member, Open Web >> Technologies - IBM Software Group > > > -- > Iovka Boneva > Associate professor (MdC) Université de Lille > http://www.cristal.univ-lille.fr/~boneva/ > +33 6 95 75 70 25
Received on Thursday, 21 May 2015 02:02:13 UTC