Re: ISSUE-133 syntax simplifications & regularizations

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.


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:// <>
>>> Homepage:
>>> Research Group: AKSW/KILT

Received on Tuesday, 10 May 2016 22:28:59 UTC