Re: Language or technology

You mean we should create something like OWL Structural Specification

     http://www.w3.org/TR/owl2-syntax/

i.e. some abstract data model only, and leave all the details to 
individual groups outside of the WG? Users would not even get a way to 
exchange their constraints in a concrete syntax?

What use would such an "abstract" standard have? And how does it solve 
the issue of trying to cast some technology into others? 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. If it just wraps 
SPARQL, how would it be different from LDOM?

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

Received on Tuesday, 27 January 2015 06:27:24 UTC