Re: on values

What are the “SHACL related graphs” that would not specify shapes?

When I read the spec, I interpret the sections that describe the vocabulary for talking about shapes and constraints as being concerned with how to describe shapes and constraints and not as talking about some other hypothetical use of this vocabulary that is not related to SHACL use cases. 

Of course, in theory, anyone could potentially say anything about anything. Thus, someone could take any term in the SHACL vocabulary and use it for something it was not designed to be used for. Therefore, one could point out, as Peter did:  “it is possible to use RDF to say {_:x sh:targetNode _:y}". The spec says you not supposed to do so when describing shapes, but you could. 

My guess is that Peter is reading the spec with a mindset that the spec must be making some very general statements about RDF. I wonder how many people will have a mindset of  “I am reading a spec about how to describe SHACL information and not about what may be possible in RDF in general” as opposed to Peter’s mindset.

If we expect the majority of readers to have Peter’s mindset, then we probably should say in every single sentence that it must be interpreted in the context of defining shapes. Just in case the readers may be thinking that they are reading about some other use of SHACL vocabulary or have no idea what document they are reading and why.

If, however, we expect most readers to understand that they are reading a document about SHACL and be interested in reading the document because they want to know how to use SHACL vocabulary to describe shapes, then setting the context repeatedly in every sentence will seriously impact readability of the spec. In this case, it is a much better approach to only say once in the introduction that the document describes the use of SHACL vocabulary to define shapes, constraints and provide any other information that is used by the SHACL processors to validate data against shapes and return validation results.

> On Dec 5, 2016, at 11:35 AM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> On 12/05/2016 12:15 AM, Dimitris Kontokostas wrote:
>> From what I understand these are two separate issues .
>> 
>> in Peter's comments, the problem he states is that we do not confine our value
>> restrictions in shapes graphs / data graphs or in  SHACL related graphs in
>> general.
>> Peter, is this the case? 
> 
> Yes indeed.
> 
>> We recently added an explanation in the conformance
>> section that the spec describes the expected structure of the language.
>> Isn't this (expected) sufficient to allow other uses of shacl properties /
>> classes?
> 
> I don't think so, for two reasons.  First, the requirements embodied in a spec
> should be blindingly obvious.  Having the wording in question be qualified by
> some comment elsewhere when it could easily be qualified locally as well is
> not being blindingly obvious.  Second, what is the SHACL language?  Is it
> shapes (in SHACL shapes graphs)?  Is it SHACL shapes graphs overall?  Is it
> SHACL data graphs?  Is it SHACL validation reports?  Is it all of these?
> 
>> Simon's comment has to do with OWL reasoning. Once OWL reasoning is applied,
>> incorrect syntax could become valid or the other way around. 
>> However, SHACL does not [do] reasoning, it takes the given graph as is
>> 
>> _:morningstar owl:sameAs :Venus. 
>>    _:x sh:targetNode _:morningstar. 
>> 
>> :morningstar owl:sameAs _:Venus. 
>>    _:x sh:targetNode :morningstar. 
>> 
>> 
>> 
>> 
>> On Mon, Dec 5, 2016 at 4:13 AM, Irene Polikoff <irene@topquadrant.com
>> <mailto:irene@topquadrant.com>> wrote:
>> 
>>    I do not understand the problem.
>> 
>>    In Simon's example _:Morningstar and :Venus are two different/separate
>>    nodes, so I am not sure what this illustrates. The fact that there is a
>>    owl:sameAs statement between a blank node and an IRI wouldn't change
>>    anything at the RDF level or SHACL level.
>> 
>>    It would help to hear from Peter what specific language makes him think
>>    the spec is talking about all RDF graphs as opposed to graphs defining
>>    SHACL shapes.
>> 
>>    Sent from my iPhone
>> 
>>    On Dec 4, 2016, at 12:49 PM, Solbrig, Harold R., M.S.
>>    <Solbrig.Harold@mayo.edu <mailto:Solbrig.Harold@mayo.edu>> wrote:
>> 
>>>    https://www.w3.org/TR/shacl-abstract-syntax/
>>>    <https://www.w3.org/TR/shacl-abstract-syntax/>
>>> 
>>>    From: Simon Spero <sesuncedu@gmail.com <mailto:sesuncedu@gmail.com>>
>>>    Date: Sunday, December 4, 2016 at 11:09 AM
>>>    To: "public-rdf-shapes@w3.org <mailto:public-rdf-shapes@w3.org>"
>>>    <public-rdf-shapes@w3.org <mailto:public-rdf-shapes@w3.org>>
>>>    Subject: Re: on values
>>>    Resent-From: <public-rdf-shapes@w3.org <mailto:public-rdf-shapes@w3.org>>
>>>    Resent-Date: Sunday, December 4, 2016 at 11:09 AM
>>> 
>>>    If I undestand the issue correctly, the problem appears to be that :
>>> 
>>>    (1) the SHACL specification needs to impose a /syntactic/ constraint on
>>>    the third position in some kinds of RDF triples - specifically that the
>>>    syntactic form MUST NOT be that of an unreified blank node (i.e. "_:x")
>>> 
>>>    but
>>> 
>>>    (2) the specification refers to the /value/ of this part of the triple,
>>>    where the syntactic form used to refer to the name is no longer
>>>    relevant; to be unoriginal, 
>>> 
>>>        _:morningstar owl:sameAs :Venus. 
>>>        _:x sh:targetNode _:morningstar. 
>>> 
>>>    It may be possible to fix the document by explicitly  distinguishing
>>>    between the syntax and semantics; alternatively it may be less confusing
>>>    to define an abstract syntax for SHACL with a mapping from that syntax
>>>    into RDF. 
>>> 
>>>    Simon
>>> 
>>> 
>>>    On Dec 3, 2016 9:51 PM, "Peter F. Patel-Schneider"
>>>    <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>> 
>>>        Certainly it is fine for the SHACL document to state conditions about
>>>        SHACL-related things (SHACL graphs, SHACL shapes, SHACL constraints,
>>>        whatever).  But the current document goes much farther.
>>> 
>>>        Of course, what the document currently says isn't anything that the
>>>        document
>>>        should be saying and almost certainly isn't what is intended.  These
>>>        parts of
>>>        the document thus need to be fixed.
>>> 
>>>        peter
>>> 
>>> 
>>>        On 12/03/2016 05:50 PM, Irene Polikoff wrote:
>>>> Firstly, I do not know if it is OK or not for this value to be a blank node. I’ll leave up to the editors to clarify.
>>>> 
>>>> Secondly, assuming it is not OK, I believe it to be totally acceptable for the SHACL spec to say that for SHACL shapes values of a specific property must not be blank nodes. Users creating shapes should not be using blank nodes as values for this property.  Such statement does not put any requirements or restrictions or
>>>        assumptions on all RDF graphs. It only concerns itself with how
>>>        shapes must be specified.
>>>> 
>>>>> On Dec 3, 2016, at 7:57 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>>>> 
>>>>> That is indeed what you said.  Prohibiting the value of sh:targetNode from
>>>>> being a blank node says something about all RDF graphs.
>>>>> 
>>>>> This is what the wording in the SHACL document is stating.
>>>>> 
>>>>> peter
>>>>> 
>>>>> 
>>>>> On 12/03/2016 04:45 PM, Irene Polikoff wrote:
>>>>>> This is not what I said
>>>>>> 
>>>>>>> On Dec 3, 2016, at 5:46 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>>>>>> 
>>>>>>> The SHACL spec can say something about all RDF graphs?  That doesn't make sense.
>>>>>>> 
>>>>>>> peter
>>>>>>> 
>>>>>>> 
>>>>>>> On 12/03/2016 02:44 PM, Irene Polikoff wrote:
>>>>>>>> By saying so in the spec.
>>>>>>>> 
>>>>>>>>> On Dec 3, 2016, at 4:09 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>
>>>>>>>>> <mailto:pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>>> wrote:
>>>>>>>>> 
>>>>>>>>> But how can the value of sh:targetNode be prohibited from being a blank node?
>>>>>>>> 
>>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Dimitris Kontokostas
>> Department of Computer Science, University of Leipzig & DBpedia Association
>> Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://aligned-project.eu
>> Homepage: http://aksw.org/DimitrisKontokostas
>> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>>

Received on Tuesday, 6 December 2016 03:57:27 UTC