Re: my vote on ISSUE-70

In general, I think it is a good idea to allow the omission of certain
triples to make life easier for authors and readers. For example, the
R2RML spec [1] does this. However, we should apply easy-to-remember
rules. Personally, I don't think blank nodes should be treated
differently than IRI nodes. If we can omit a type triple for a blank
node, then we should also omit it for an IRI.

[1] http://www.w3.org/TR/r2rml/

-- Arthur

On Thu, Aug 27, 2015 at 4:52 PM, Holger Knublauch
<holger@topquadrant.com> wrote:
> 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, 17 September 2015 17:59:44 UTC