Re: ISSUE-133 syntax simplifications & regularizations

Currently there is a need for such a property because of the division between
shapes and constraints.  If that division is eliminated or reduced then there
may not be any reason to have such a property.

Right now, the shape to validate that all nodes that belong to ex:Person are
IRIs (i.e., not blank nodes) is something like

sh:piri a sh:Shape ;
 sh:scopeClass ex:Person ;
 sh:constraint [ a sh:NodeConstraint ;
                 sh:nodeKind sh:IRI ] .

The property sh:constraint (or sh:node, or sh:self) is needed to bridge the
syntactic divide between shapes and constraints.  If this divide is reduced
then it could be possible to instead have something like

sh:piri2 a sh:Shape ;
  sh:scopeClass ex:Person ;
  sh:nodeKind sh:IRI .

peter


On 05/10/2016 02:57 PM, 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:13:26 UTC