Re: ISSUE-95: Template Simplifications

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_Simplifications
>
> -- Arthur
>
>

Received on Thursday, 29 October 2015 12:23:29 UTC