W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > January 2015

Re: Language or technology

From: Holger Knublauch <holger@topquadrant.com>
Date: Tue, 27 Jan 2015 16:58:03 +1000
Message-ID: <54C736FB.3030802@topquadrant.com>
To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>

On 1/27/15, 4:41 PM, Jose Emilio Labra Gayo wrote:
> On Tue, Jan 27, 2015 at 7:26 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>     You mean we should create something like OWL Structural Specification
>     http://www.w3.org/TR/owl2-syntax/
>     i.e. some abstract data model only, 
> No, I mean we should create some structural syntax like the one for 
> OWL accompanied with a well defined semantics as:
> http://www.w3.org/TR/2012/REC-owl2-direct-semantics-20121211/

Such a thing already exists, it's called SPARQL. There is no need to 
reinvent what it means to count triples or to compute a + b. And the 
mapping of something like maxCardinality is already specified in LDOM 

>     and leave all the details to individual groups outside of the WG? 
> No, the individual groups should have to validate their 
> implementations against the test cases and the semantics wedefined by 
> the WG

But where is anything that end users can use here, if you end up with a 
number of vendor-specific syntaxes that are not standardized? We would 
be back to square one and end up with nothing useful at all.

>     Users would not even get a way to exchange their constraints in a
>     concrete syntax?
> We could define some concrete syntax...which as I said, could be RDF 
> or something more human-friendly.

I propose LDOM for that role and skip your other abstract documents.

>     What use would such an "abstract" standard have? 
> As I said, it would not just be the abstract standard...we could also 
> have some reference implementation.
>     And how does it solve the issue of trying to cast some technology
>     into others? 
> Because there is a well defined semantics on the agreed terms that we 
> have found, letting the controversial terms as unspecified.

LDOM will be 100% well-defined - every term has a SPARQL query behind 
it. There is nothing controversial.

>     You basically just create another layer of indirection that all
>     languages have to map into, while LDOM directly maps into SPARQL
>     which is already well-established and supported by all triple stores. 
> We could maintain SPARQL compatibility also. We could define a mapping 
> to SPARQL as a recommendation if you prefer.

Looking at the requirements catalogue (string operations, language tags, 
aggregations etc) it is clear that the language would actually have to 
be SPARQL itself. Why invent another language all over again?

>     If it just wraps SPARQL, how would it be different from LDOM?
> LDOM as far as I know now has not a well defined semantics. Its 
> semantics appears to be in natural language accompanied with *your* 
> implementation.

The detailed LDOM spec will have this written up so that anyone can 
implement it, of course.

> We can not reason about LDOM nor compare if some constraints expressed 
> in LDOM are equivalent to other constraints...for example, how could 
> you assert that one shape defined in LDOM is equivalent to another?

Which user story and requirement needs such static analysis?

So far this feels like a step in a very wrong direction to me.

Received on Tuesday, 27 January 2015 06:58:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 27 January 2015 06:58:36 UTC