- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 10 May 2016 14:57:59 -0700
- To: public-data-shapes-wg@w3.org
"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 >> > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Tuesday, 10 May 2016 22:00:41 UTC