Re: my vote on ISSUE-70

My view, as stated in
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Aug/0119.html,
is that there should be no special treatment of blank nodes in SHACL syntax.

So, either neither or both of

  ex:shape2 sh:property ex:constraint .
  ex:constraint sh:predicate ex:myProperty .
  ex:constraint sh:minCount 1.

  ex:shape1 sh:property _:constraint .
  _:constraint sh:predicate ex:myProperty ;
  _:constraint sh:minCount 1.

should be legal.

I prefer neither being legal over both being legal.


Neither Turtle nor JSON-LD will produce readable SHACL syntax.  If you want a
readable syntax for SHACL then use a non-RDF syntax, like the ShEx syntax.

peter


On 08/26/2015 04:31 PM, Holger Knublauch wrote:
> On 8/27/2015 8:48, Peter F. Patel-Schneider wrote:
>> Is
>>
>>    ex:shape2 ex:property ex:constraint .
>>    ex:constraint sh:predicate ex:myProperty ;
>>        sh:minCount 1.
>>
>> legal SHACL?
> 
> (I assume you meant sh:property instead of ex:property above)
> 
>> If not, then blank nodes are getting special treatment.
> 
> My main goal is to have some mechanism to allow the syntactic shortcut in
> constraint and shape definitions. This in particular applies to making Turtle
> and JSON-LD code as readable as possible. Many people will prefer blank nodes
> over creating (detached) URI nodes. As soon as such a node gets a URI, I
> believe it SHOULD also have a rdf:type triple. This is because in practice it
> becomes much more likely that someone will stumble upon such URIs in
> isolation, without the context of incoming references that is naturally
> provided by Turtle of JSON-LD syntax.
> 
> While some of this may sound theoretic, there is a very practical aspect to it
> that I ran into when I implemented (TopBraid) tool support: resources often
> need to be rendered as a string or with an icon. The string for constraints
> should be useful to humans, and not just a bnode ID, and the icon should
> indicate that this is a property constraint. The algorithms that create those
> labels and icons usually only get the resource as input parameter, and need to
> figure out the rest from there. My current implementation can first check if
> an untyped node is a blank node, and only then start special treatment of
> finding incoming references. With blank nodes, there is usually just one
> incoming reference, so this is a low risk activity. With IRI nodes there may
> be a lot of values to walk through, only to find out what the display label
> should be, and especially there may be many false alarms where all these look
> ups happened in vain.
> 
> So my preference would be to only apply this special treatment to blank nodes.
> 
> Could you explain why you are against this, i.e. why you think this should
> also apply to IRIs, or what your counter proposal is?
> 
> Thanks,
> Holger
> 
> 
>>
>> peter
>>
>> On 08/26/2015 03:25 PM, Holger Knublauch wrote:
>>> Hi Peter,
>>>
>>> I believe we are talking about the same thing (the first option). At
>>> validation runtime there is no need for special treatment of the blank nodes
>>> (where the property is marked with a sh:defaultValueType). So for example, the
>>> engine can safely assume that every typeless blank node value of sh:valueShape
>>> is indeed a sh:Shape.
>>>
>>> The pre-computation of the "missing" triples is entirely optional and may be
>>> done by a tool to support validation of a shapes graph itself, when the user
>>> requests that. For example, if the values of sh:valueShape shall be validated
>>> against the constraints of sh:Shape, then the triple would be needed and the
>>> provided SPARQL query can be used to "infer" those triples prior to
>>> "meta"-validation.
>>>
>>> Holger
>>>
>>>
>>> On 8/27/15 7:15 AM, Peter F. Patel-Schneider wrote:
>>>> ISSUE-70: blank node default type
>>>>
>>>> PROPOSED: Close ISSUE-70, by stating that sh:valueClass constraints do not
>>>> need special treatment of blank nodes, but that the implicit rdf:type triples
>>>> for certain blank nodes can be pre-computed by an engine whenever the user
>>>> requests validation of shape structures.
>>>>
>>>>
>>>>
>>>> I don't understand this proposal.  Does it say that these constructs, and
>>>> similar ones, never need rdf:type triples (no special treatment)?  Or does it
>>>> say that type triples are needed for non-blank nodes that appear in these
>>>> constructs and that missing type triples for blank nodes that appear in these
>>>> constructs can be pre-computed somehow (special treatment)?
>>>>
>>>> I'm OK with the former, but not with the latter.
>>>>
>>>>
>>>> peter
>>>>
>>>>
>>>
> 
>

Received on Thursday, 27 August 2015 12:35:48 UTC