Re: ISSUE-95: Template Simplifications

Arthur,

I believe the ease of implementing a full SHACL engine to be very
important. If it is hard to implement, there will be no SHACL engines and,
thus, no reason to write SHACL documents.

I totally agree that creating SHACL documents should not be
overcomplicated. However, addressing this goal by making implementations
significantly more complex is not the right idea. There must be a way to
meet both goals. 

Besides, presence of meta-classes in the underlying model doesnąt
necessarily makes writing SHACL documents more complex. For example, I
donąt think that meta-classes in RDFS or OWL made creating RDFS/OWL models
or creating RDF data more complex. I also think that majority of people
will be using tools to define SHACL Shapes - just like they use tools
today for OWL models, UML models, XML Schemas, etc.


Irene Polikoff





On 10/29/15, 8:23 AM, "Arthur Ryman" <arthur.ryman@gmail.com> wrote:

>Holger,
>
>1. Yes, I agree that we need a concrete alternative for the SHACL data
>model. We should start with a minimal Turtle vocabulary file which
>contains all the terms we use in the spec and only add features agreed
>to by the WG.
>
>2. I believe the WG should give first precedence to making SHACL easy
>to understand for people who are going to write SHACL documents. We
>should not sacrifice that for technical advantages related to
>validating SHACL documents.
>
>3. My second line of reasoning relates to the use of meta-classes. I
>believe it is very easy to get lost when mentally traversing
>meta-levels. I believe data models are easier to understand when
>meta-classes are avoided. I believe the OWL approach of classifying
>all terms as classes, properties, or individuals results in data
>models that are easier to understand. Yes, avoiding meta-classes is a
>matter of personal taste but it makes data models clearer.
>
>-- Arthur
>
>On Wed, Oct 28, 2015 at 8:55 PM, Holger Knublauch
><holger@topquadrant.com> wrote:
>> Hi Arthur,
>>
>> I will vote -1 for your proposals.
>>
>> First, you (or someone) should provide the details, including a Turtle
>>file,
>> on how all this is supposed to work. I am certainly not going to spend
>>my
>> own time on something which I don't think is broken. On a topic as
>>technical
>> as this specific mechanism, it is IMHO not sufficient to just throw in
>>some
>> high-level ideas. The devil is in the details. For example, how is this
>> supposed to work for constraints based on validation functions?
>>
>> Second, I believe your line of argumentation boils down to personal
>>taste.
>> Yes, people can have different preferences and regard one approach more
>> elegant and clearer, or another approach more consistent. However, I
>>have
>> given *specific technical advantages*, namely the ability to use
>>exactly the
>> same mechanisms to validate Shapes files and to reuse user interface
>> mechanisms and the corresponding SPARQL queries to find "relevant"
>> properties. Your proposal would create significant additional costs to
>> implementers, and break the consistency of using SHACL to describe data
>> structures, for a something that is essentially personal taste.
>>
>>> I see no compelling reason to define sh:Argument as a kind of
>>> sh:Constraint when we have the option of separating them.
>>
>> So you don't believe there is benefit in being able to validate shapes
>> graphs? Then you go on with the usual Shapes-vs-Classes discussion,
>>which is
>> entirely about syntactic sugar. We only need to discuss all this if we
>> decide to disallow shapes as classes - otherwise it is perfectly legal
>>to
>> use our own mechanisms and shortcuts. Avoiding the duplicatation of
>> sh:Argument as sh:ArgumentShape is exactly one of the reasons why I
>>argue
>> that shapes and classes should be mixable. Yes, every data model could
>>be
>> split into two files - one for the classes and one for the shapes. But I
>> would argue this is an anti-pattern for vocabularies such as SHACL that
>>have
>> a very specific global meaning.
>>
>> You also state that the class hierarchy is undocumented. We have an open
>> ticket about the inclusion of the Turtle file, which would address this.
>>
>> Regards,
>> Holger
>>
>>
>>
>> On 10/29/2015 7:49, Arthur Ryman wrote:
>>
>> WG,
>>
>> As per our SOP, I have added a comment with proposals to the Proposal
>> page in the wiki [1]. Please review. Thx.
>>
>> [1]
>> 
>>https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-95:_Template_Sim
>>plifications
>>
>> -- Arthur
>>
>>
>

Received on Thursday, 29 October 2015 23:37:35 UTC