Re: my vote on ISSUE-70

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 Wednesday, 26 August 2015 23:31:49 UTC