W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > September 2016

Re: Deep copy

From: Holger Knublauch <holger@topquadrant.com>
Date: Tue, 27 Sep 2016 10:11:56 +1000
To: "public-rdf-sha." <public-rdf-shapes@w3.org>
Message-ID: <b19151a8-da91-548e-1116-64ae4d700bfb@topquadrant.com>
There is a fine line between being sufficiently precise for 
implementers, and still being readable by humans. It is easy to 
overreach in one direction or the other. There has already been a lot of 
criticism on the spec being too formal. As an editor, I cannot make 
every viewpoint perfectly happy. While some of your comments make sense, 
others go IMHO too far into the formal spectrum.

Holger


On 27/09/2016 9:58, Peter F. Patel-Schneider wrote:
> On 09/26/2016 04:16 PM, Holger Knublauch wrote:
>> On 27/09/2016 1:46, Peter F. Patel-Schneider wrote:
>>> Equivalent is undefined here.
>> Equivalent is an English word. We could apply the same process to basically
>> every term that is used in the spec. Where would this stop? At some stage, I
>> assume, the reader is able to infer certain things and apply common sense.
> Every English word is an English word, including "equivalent".  In
> specification documents, however, there are many words that generally require
> a formal definition so that their precise meaning in the specification can be
> determined, either because the common English meaning of the word is vague or
> ambiguous or because the word signals a significant relationship in the
> specification.  "Equivalent" has both of these characteristics.
>
> There is no way that a reader could determine with any certainty what
> equivalent means here.  For example, can the order of elements in an
> alternatives list be changed?  If a node in a list that forms part of the path
> is an IRI, can that node be replaced by a different node if there would be no
> change to the results of the SPARQL queries generated?  What if this node is
> blank node?  Can it then be changed?  What about links from nodes in the path
> that don't contribute to the path?  Do these links need to show up in the new
> path?
>
> Understanding what things need to be defined in a specification is a basic
> part of the skills needed to create a viable specification.
>
>>> I'm assuming that the idea is to copy the list structure that makes up the
>>> SHACL path, but not other structure.  However, at this time it is not possible
>>> to define what this should be because the definition of SHACL paths has gaping
>>> holes.
>> What gaping holes are you referring to? I cannot fix things if I don't know
>> what needs to be fixed.
> I suggest reading the recent messages to the comments mailing list, in particular
> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Sep/0035.html
>
>> Thanks,
>> Holger
> Peter F. Patel-Schneider
> Nuance Communications
>
>
>>> It is up to the working group to come up with workable definitions for such
>>> important parts of SHACL.
>>>
>>> Peter F. Patel-Schneider
>>> Nuance Communications
>>>
>>> On 09/25/2016 11:59 PM, Holger Knublauch wrote:
>>>> I have made another attempt at this sentence:
>>>>
>>>> The value of <code>sh:path</code> of each validation result must point to a
>>>> <a>SHACL property path</a> that <a href="#path-syntax">represents</a> an
>>>> equivalent path like the one provided in the constraint.
>>>>
>>>> Is that any better? If not, can you suggest better wording?
>>>>
>>>> Holger
>>>>
>>>>
>>>>
>>>> On 25/09/2016 7:35, Peter F. Patel-Schneider wrote:
>>>>> I'm assuming that you mean
>>>>>
>>>>> The value of sh:path of each validation result must point to a SHACL property
>>>>> path that is identical to the path provided in the constraint.
>>>>>
>>>>> This is actually worse.  Identical is not defined at all in the SHACL
>>>>> document
>>>>> and there is no pointer to an external meaning.  There is no useful guidance
>>>>> to be found in the RDF documents either.  Falling back on general principles
>>>>> would result in either identical nodes or identical graphs, both of which
>>>>> make
>>>>> sense in an RDF setting, but neither of which are what is wanted here, I
>>>>> think.
>>>>>
>>>>> The solution that is needed is to define a notion of
>>>>> equivalence/identicalness
>>>>> for SHACL property paths.  The section on property paths needs a complete
>>>>> rewrite anyway so defining identical/equivalent SHACL property paths can be
>>>>> part of this needed change.
>>>>>
>>>>> peter
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 09/24/2016 07:29 AM, Dimitris Kontokostas wrote:
>>>>>> Thank you Peter,
>>>>>>
>>>>>> can you check if the latest version has any issues?
>>>>>>
>>>>>> Best,
>>>>>> Dimitris
>>>>>>
>>>>>> On Fri, Sep 23, 2016 at 8:36 PM, Peter F. Patel-Schneider
>>>>>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>>>>>
>>>>>>        Your reasoning is incorrect.
>>>>>>
>>>>>>        It appears that what you mean by "deep copy" is somewhat related to
>>>>>> its
>>>>>>        meaning in LISP.  The meaning of "deep copy" that most readers will
>>>>>> know of is
>>>>>>        is meaning in current object-oriented languages, where all objects
>>>>>> reachable
>>>>>>        by inter-object links are copied.  This would end up copying the
>>>>>> entire
>>>>>>        portion of the RDF graph reachable from the head list node, which is
>>>>>> not what
>>>>>>        is desired here.
>>>>>>
>>>>>>
>>>>>>        Peter F. Patel-Schneider
>>>>>>        Nuance Communications
>>>>>>
>>>>>>
>>>>>>        On 09/22/2016 10:38 PM, Holger Knublauch wrote:
>>>>>>        > On 23/09/2016 11:36, Peter F. Patel-Schneider wrote:
>>>>>>        >>
>>>>>>        >>> Deep copy
>>>>>>        >>>
>>>>>>        >>> "a deep copy of sh:path as its sh:path" What is "deep copy" in
>>>>>> this
>>>>>>        >> context?
>>>>>>        >>>      Comment (HK): I have attempted to clarify this here:
>>>>>>        >>
>>>>>>      
>>>>>> https://github.com/w3c/data-shapes/commit/d3f8f858f95b010d1f2a0e4681da203bcbfbc217
>>>>>>
>>>>>>
>>>>>>      
>>>>>> <https://github.com/w3c/data-shapes/commit/d3f8f858f95b010d1f2a0e4681da203bcbfbc217>
>>>>>>
>>>>>>
>>>>>>        >>
>>>>>>        >>>      Comment (kc): Unless "deep copy" has some pre-defined meaning
>>>>>> that I
>>>>>>        >> am unaware of, I would suggest dropping it and saying: The value of
>>>>>> sh:path
>>>>>>        >> of each validation result must copy all triples that are required
>>>>>> by the <a
>>>>>>        >> href="#path-syntax">SHACL well-formed path syntax rules</a>from the
>>>>>>        >> <a>shapes graph</a> into the graph containing the validation
>>>>>> results.
>>>>>>        >>>      Comment (HK): The first google match of "deep copy" is pretty
>>>>>>        close to
>>>>>>        >> what I wanted to express, so I believe the term should be familiar
>>>>>> to many
>>>>>>        >> people and may be helpful for implementers. Also I had surrounded
>>>>>> the term
>>>>>>        >> with "...". Anyway, I have no strong opinion and let others decide.
>>>>>>        >>
>>>>>>        >> The extra wording is helpful.  However, "deep copy" in
>>>>>>        >> https://en.wikipedia.org/wiki/Object_copying#Deep_copy
>>>>>>        <https://en.wikipedia.org/wiki/Object_copying#Deep_copy> is
>>>>>> different.  Either
>>>>>>        >> drop "deep copy" or point to an appropriate definition.
>>>>>>        >
>>>>>>        > Almost every English word is somehow overloaded with multiple
>>>>>> meanings. I
>>>>>>        > believe your linked deep copy is quite appropriate for what I am
>>>>>> trying to
>>>>>>        > express. If anyone has a suggestion on how to explain this better,
>>>>>> please
>>>>>>        > provide a complete replacement of the sentence - just dropping the
>>>>>> term does
>>>>>>        > not work.
>>>>>>        >
>>>>>>        > Thanks,
>>>>>>        > Holger
>>>>>>        >
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> 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, 27 September 2016 00:12:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:44 UTC