Language or technology

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