- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 27 Sep 2016 06:30:42 -0700
- To: public-rdf-shapes@w3.org
On 9/26/16 5:11 PM, Holger Knublauch wrote: > 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. I'm not aware of any criticism of the spec being "too formal". Instead, what I have heard is that it is unclear - and that is from people who are experienced at reading formal specs. I'm willing to do a read-through to point out areas that I see that are unclear, or at least to point out some examples that would help make this issue more concrete. kc > > 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 >>>>>>> >>> > > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Tuesday, 27 September 2016 13:31:26 UTC