- From: Holger Knublauch <holger@topquadrant.com>
- Date: Wed, 11 May 2016 08:28:25 +1000
- To: public-data-shapes-wg@w3.org
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