Re: my vote on ISSUE-70

On 8/27/15 10:35 PM, Peter F. Patel-Schneider wrote:
> 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.

Yes I see that you stated this, but I don't find an explanation why you 
believe this way. Providing a bit more explanation would probably help 
me change my mind.

>
>
> 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.

There are certainly some examples of SHACL that don't look very good in 
Turtle or JSON-LD, but there are plenty of examples that will look good. 
We should at least try our best. For example look at what JSON people 
consider acceptable:

http://json-schema.org/examples.html

{
     "title": "Example Schema",
     "type": "object",
     "properties": {
         "firstName": {
             "type": "string"
         },
         "lastName": {
             "type": "string"
         },
         "age": {
             "description": "Age in years",
             "type": "integer",
             "minimum": 0
         }
     },
     "required": ["firstName", "lastName"]
}

The SHACL equivalent in JSON-LD would be

{
     "@id" : "ExampleShape" ,
     "@type" : "Shape",
     "property" : [
         {
             "predicate" : "ex:firstName",
             "datatype" : "string",
             "minCount" : 1
         } ,
         {
             "predicate" : "ex:lastName",
             "datatype" : "string",
             "minCount" : 1
         } ,
         {
             "predicate" : "ex:age",
             "comment" : "Age in years",
             "datatype" : "integer",
             "minInclusive" : 0
         }
     ]
}

which I believe is very readable and easy to process. And in contrast to 
the Compact Syntax drafts that I have seen this is at least extensible 
and consistent.

Looks like yet another disagreement between us where we need input from 
other WG members. (We didn't tackle the issue today because you had sent 
regrets).

Thanks,
Holger

>
> 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 20:52:52 UTC