Re: Deep copy

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

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

> 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
>>>>> < <>> 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:
>>>>>       >>
>>>>> <>
>>>>>       >>
>>>>>       >>>      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
>>>>>       >>
>>>>>       <> 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:,,
>>>>> Homepage:
>>>>> Research Group: AKSW/KILT

Received on Monday, 26 September 2016 23:59:18 UTC