Re: ISSUE-133 syntax simplifications & regularizations

"self" will make sense to some folks who have been introduced to the 
concept in certain programming languages, but not everyone has that 

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:

Given that we've lived for so many years learning seemingly nonsense 
terms like "grep" I think that shortenings that are mnemonic are fine.


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

Karen Coyle
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Tuesday, 10 May 2016 22:00:41 UTC