Re: Readability in the face of complexity and internationalisation of human friendly syntaxes for constraints and documentation

On Aug 7, 2014 9:54 AM, "Holger Knublauch" <> wrote:
> On 8/7/2014 8:37, Jerven Bolleman wrote:
>> Hi All,
>> This is just food for thought to be considered by the WG when it forms.
>> The key ideas are:
>>   * complexity needs to be managed not ignored.
> I fully agree. Another point that a short syntax such as ShExC completely
lacks is that if you want to properly publish a "schema" then you also need
a way to define the properties and classes that are used, together with
their rdfs:labels, rdfs:comments, relationships etc. These are attached to
the properties globally, and already exist in triple format. Developers
would end up using a Turtle/JSON-LD file for one part of their schema, and
then a custom syntax just for the constraints? And then this custom syntax
is only covering the hand-picked selection of commonly used constraints,
but for other ones you need to again fall back to RDF syntaxes. Why even

My approach to this and what I do with RDFUnit is to declare only the
schemas you want and in addition all the manual  constraints on top of
that. Something like:

Use: foaf,dcterms,skos
Manual constraints: C1,C2,C3

What I do in the background is to automatically convert all the
foaf,dcterms,skos axioms into sparql test cases and additionally load the
manually defined constraints C1, C2, C3

Regardless of the validation syntax, the user doesn't need to know what is
produced from the schemas. These are disposable constraints and the
validation engine can hide them and simplify the whole process.
Provided of course that the conversion is standardised.

Taking this into Shapes, the user can define for example I want to use foaf
and each foaf:Person must have 1 foaf:name &1 foaf:homepage.

For most use cases this works perfectly fine, for more advanced, one can
skip the "use foaf" directive and set everything manually.


Received on Thursday, 7 August 2014 14:05:08 UTC