Re: Language or technology

On Tue, Jan 27, 2015 at 7:26 AM, Holger Knublauch <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/

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


> 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.

>
> 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.


> 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.


> 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.

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?

Best regards, Jose Labra


> Holger
>
>
>
> On 1/27/15, 3:56 PM, Jose Emilio Labra Gayo wrote:
>
>> Given all the discussions that are appearing trying to cast some
>> technologies into others, I would like to propose a pragmatic solution for
>> the WG.
>>
>> In my opinion the WG could concentrate in defining an RDF constraint
>> validation language with a simple and well defined semantics but with
>> different syntaxes and implementations.
>>
>> From my point of view, there is a common subset of all the proposals
>> which can be captured by this language.
>>
>> The advantages on concentrating on a language, instead of a full stack
>> technology or implementation would be:
>>
>> - It could have a well defined semantics which could be understood
>> without having to know a different technology
>>
>> - It could have different syntaxes. We should have RDF, but we could also
>> define some more human friendly syntaxes like ShExC or whatever proposal
>> may arrive.
>>
>> - It could have several independent implementations, which is a
>> requirement for it to become a recommendation. For example, we could
>> implement it using SPIN/LDOM, or directly as has been done in the case of
>> ShEx in Javascript, Scala or whatever programming language. It could also
>> be mapped to OWL constructs. In fact, one possibility would be that the
>> semantics could be defined in terms of OWL.
>>
>> - It could have a set of well defined test cases which could be checked
>> based on that semantics. Maybe, there could be even some reference
>> implementation to automatically check the test cases.
>>
>> - It could separate the step of constraint validation from the step of
>> node selection for validation. I think one of the main differences with
>> SPIN is that they prefer to have a node validation policy based on the
>> rdf:type predicate, while other proposals are more liberal and prefer to
>> leave that node selection unspecified. This does not mean that the other
>> proposals could have node selection by rdf:type, it just means that there
>> can be that mechanism, but also other mechanisms for node selection.
>>
>> - It could have some extensibility mechanisms which would enable to
>> define complex constraints by some means that does not need to be covered
>> by this working group. As an example is to have some escape construct to
>> add constraints using SPARQL queries, which is a mechanism proposed both by
>> SPIN and ShEx (semantic actions). But it could also have that same
>> mechanism to allow the users to define constraints in other languages of
>> their preference but which would be specific to the processor of those
>> languages.
>>
>> - It could also define the information that the constraint validation
>> process returns, so it would be easy to generate human-readable error
>> messages from that information.
>>
>> From my point of view, if we concentrate on this task, we are going to be
>> able to have a well defined recommendation that will solve the problems
>> that this WG has been asked to solve.
>>
>> And it is feasible to have independent implementations of that language
>> (I think SPIN/LDOM could be easily adapted to provide those
>> implementations) and depending of the features of that language, I could
>> also adapt my ShEx implementation to it and probably Eric could adapt his
>> implementation. Maybe, even Peter could help with the mappings to
>> OWL...from my point of view, in this case, less is more and we would be
>> able to join forces to define such a needed recommendation.
>>
>> This is also a common way to proceed for WGs, they define languages, not
>> technologies. Trying to conflate language with technology will only
>> constrain our work and generate more problems and misunderstandings.
>>
>> --
>> Best regards, Labra
>>
>
>
>


-- 
Saludos, Labra