W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > May 2016

Re: ISSUE-133 syntax simplifications & regularizations

From: Holger Knublauch <holger@topquadrant.com>
Date: Wed, 11 May 2016 08:28:25 +1000
To: public-data-shapes-wg@w3.org
Message-ID: <bad34928-43bb-ebe7-9a4e-a02e022b9aa4@topquadrant.com>
First thanks to Dimitris for suggesting spawning off the 
SPARQLConstraints with a dedicated property sh:sparqlConstraint. This 
allows us to reduce the need for a default value type concept. (A 
similar concept remains there in a sense, but it would have a simpler 
contract that is similar to rdfs:range).

On the naming front, I think we could continue using sh:constraint. We 
also have sh:sparqlConstraint. Even node constraints can in principle 
check property values, so they are in fact quite general. I am not too 
excited about sh:node or sh:self but would not vote against those 
either. In the end it's just a name that people need to learn.

Holger



On 11/05/2016 7:57, Karen Coyle wrote:
> "self" will make sense to some folks who have been introduced to the 
> concept in certain programming languages, but not everyone has that 
> experience.
>
> I'm not entirely sure why an additional property is needed to 
> designate the node since the focus node has been identified at this 
> point and, I presume, can be the subject of triples that carry 
> constraints. The property and inverseProperty constraints are the ones 
> that have the need to further identify their target.
>
> If a property is necessary for the constraints on the node, then I'd 
> give it a name like "nodeConstraint" or something other than node that 
> means that it is the constraints on the node. sh:property is not a 
> good name for a constraint since nothing about it implies/recalls 
> constraint, so I'd want to see something there that sets it apart from 
> a simple property, such as "sh:propertyConstraint". If there is a 
> desire for a shorter name, there are lots of options:
> sh:nodeC
> sh:nConstraint
> sh:propertyC
> sh:propConstraint
> sh:propCon
>
> Given that we've lived for so many years learning seemingly nonsense 
> terms like "grep" I think that shortenings that are mnemonic are fine.
>
> kc
>
> On 5/10/16 1:24 PM, Peter F. Patel-Schneider wrote:
>> I suggest sh:self as a better name for sh:node.
>>
>> peter
>>
>>
>> On 05/10/2016 07:36 AM, Dimitris Kontokostas wrote:
>>> After a quick offline discussion with Holger we would like to 
>>> propose some
>>> work towards syntax simplification
>>>
>>> The proposal has 2 aspects that go together
>>> 1. we remove the sh:defaultValueType from SHACL (Peter also had 
>>> concerns with
>>> this - see issue-128)
>>> 2. we simplify sh:constraint in the following ways
>>>
>>> a. sh:constraint is renamed to sh:node (other names welcome) and may 
>>> have only
>>> values of sh:NodeConstraint type
>>> b. native sparql constraints (which could be used inside 
>>> sh:constraint) are
>>> now declared separately using a new property sh:sparqlConstraint 
>>> that allows
>>> only sh:SparqlConstraints
>>>
>>> We believe this is a simplification everyone will like and would 
>>> like to put
>>> it in the agenda for the next telco. Any comments are welcome
>>>
>>> rational for this change is the discussion for wording section 2.3.
>>> sh:defaultValueType was complicating things and one of the reasons 
>>> it was
>>> introduced is to disambiguate the values of sh:constraint.
>>> With this change every predicate can have only one possible type now
>>> and sh:defaultValueType is no longer needed
>>>
>>> Best,
>>> Dimitris
>>>
>>> -- 
>>> Dimitris Kontokostas
>>> Department of Computer Science, University of Leipzig & DBpedia 
>>> Association
>>> Projects: http://dbpedia.org, http://rdfunit.aksw.org,
>>> http://http://aligned-project.eu <http://aligned-project.eu/>
>>> Homepage:http://aksw.org/DimitrisKontokostas
>>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>>>
>>
>>
>
Received on Tuesday, 10 May 2016 22:28:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:33 UTC