- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Thu, 14 Jul 2016 11:21:38 +0300
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a16gOFtNZTe2BJdF+eR+Ag+U3-3Cc1mRyzQXpif_aGy3A@mail.gmail.com>
On Tue, Jul 12, 2016 at 7:12 PM, Karen Coyle <kcoyle@kcoyle.net> wrote: > Thanks, Dimitris. As I said in my response to myself, Yes, property scopes > do what I was looking for. It is confusing that SHACL refers to predicates > in many of its explanations of scopes, but calls the scope that takes a > predicate identifier for scope selection a "property scope". I can > understand why, to some extent, but there is a moving back and forth > between "predicate" and "property" that causes me confusion. I would prefer > that we use the terms of the RDF abstract syntax consistently, and always > use the same term for the same thing. > Holger's proposal to rename these property scope selectors would help in this regard https://www.w3.org/2014/data-shapes/track/issues/169 (which I am also in favor of) However you are right in this, we use both predicate and property a lot in the spec, not only in prose but also as sh:property / sh:predicate sh:property denotes Property constraints (Constraints that are about a particular property or path and its values for the focus node) here property actually means predicate as property is a more general term that can take part as subject/objecty in a triple I think we copied this terminology from IBM Resource Shapes and for most (technical) people the distinction is clear but I see your point of confusion. One way to reduce this confusion would be to rename sh:property to something else e.g. sh:value. This would be a very big syntax change (that I would avoid) but I wouldn't object if there was strong support. But this should be decided as soon as possible together with the rest of the upcoming changes. > I understand that all scopes are nodes. (it might be good to say that in > the spec). Defining a scope in terms of a predicate IRI results in a scope > that is a node (either the subject or object of the predicate IRI). My > original question was, if my data graph has this triple: > > <a> <ex:IRI> <b> > > and sh:scopenode = ex:IRI, is this triple in scope? I am assuming that it > is not, because ex:IRI is not a node, but I haven't been able to get a > clear answer. > The definition "A node scope with value $scopeNode, defines $scopeNode as > the node in-scope in the data graph" reads as being circular (a node scope > is a node in scope), so I'd like to see a definition that is more along the > lines of: > > When the value of sh:scopeNode matches the value of any node (subject or > object of a triple) in the data graph, that node is the focus node that is > in scope for matching against the defined constraints. > > That may be too long, but I can't think of anything shorter at the moment. > Basically, the definition needs to say both what the action is but also > what the result is. The current definition says that, but the tautology of > "scope node is node in scope" makes it hard to read. > I hope the updated definitions are clear and this is no longer an issue > Also, the meaning of "in scope" has not been defined in the document > before that point, AFAIK, so "in scope" isn't meaningful. And again, there > seem to be two parallel terms (node in scope, and focus node) that aren't > clearly differentiated. Are they different? They both appear to apply to > the data graph, although in the definitions "scope" is an aspect of the > SHACL graph - however "in scope in the data graph" seems to belie that. > The way validation is defined now is that it starts with an RDF node and we validate the node itself (NodeConstraints) or it's values through a predicate or a path (PropertyConstraints) Scopes are one way to define the RDF nodes in-scope that in turn become focus nodes after the pass any filtershapes the other way to define focus nodes is through shape references e.g. with sh:shape so, since validation starts with a node, having ex:IRI as a focus node, when ex:IRI exists only as predicate in the data graph, would be something like a silly thing to do (to reuse recent terminology :) ) depending on the constraints that are defined some would always be wrong and some always true Dimitris > > kc > > > > On 7/12/16 6:55 AM, Dimitris Kontokostas wrote: > >> Hi Karen >> >> On Mon, Jul 11, 2016 at 11:02 PM, RDF Data Shapes Working Group Issue >> Tracker <sysbot+tracker@w3.org <mailto:sysbot+tracker@w3.org>> wrote: >> >> shapes-ISSUE-174 (Scopenode): Scopenode does not use RDF node >> definition [SHACL - Core] >> >> http://www.w3.org/2014/data-shapes/track/issues/174 >> >> Raised by: Karen Coyle >> On product: SHACL - Core >> >> After chatting with various folks I am convinced that the use of >> "node" in the definition of "node scope" in SHACL is not correct. >> Node in RDF (which definition SHACL claims to follow) is defined thus: >> >> "The set of nodes of an RDF graph is the set of subjects and objects >> of triples in the graph. It is possible for a predicate IRI to also >> occur as a node in the same graph."[1] >> >> When we look at that: >> >> "The set of nodes of an RDF graph is the set of subjects and objects >> of triples in a graph." >> >> -> Only subjects and objects are "nodes." >> >> "It is possible for a predicate IRI to also occur as a node in the >> same graph." >> >> This refers to the IRI that is a predicate in a graph, not the >> predicate position in the triple, which is always an "arc" and not a >> node. The IRI can be a node (a subject or an object) if it is the >> subject or object of a triple. This means that if you "say >> something" about the predicate (for example adding a provenance >> statement about the predicate) then it has become a node in a graph >> as well as being a predicate in the graph. >> >> In fact, most predicates are not also subjects or objects. This >> means that at the moment SHACL does not have a way to define a scope >> on predicates. >> >> >> At the moment, SHACL and all existing parallel proposals (correct me if >> I am wrong) including ShEx & Peter's proposal work on RDF nodes. >> No proposal has any special treatment for predicates, when the >> predicates do not exists as subjects / objects on the graph to be tested >> >> >> If the above holds true, then two things must happen: 1) SHACL must >> not use "node" where it means all components of a triple and >> >> >> We do not currently have any discussion on how a predicate can work as >> scope nor any use-cases. e.g. what does it mean to to have e.g. >> rdfs:label as scope? >> >> however, we do have sh:scopeProperty and sh:scopeInverse property >> >> e.g. sh:scopeProperty rdfs:label selects all subjects in the data graph >> that appear in a triple with rdfs:label as predicate >> e.g. sh:scopeInverseProperty rdfs:label selects all objects in the data >> graph that appear in a triple with rdfs:label as predicate >> >> in that sense I think the term node here is correct >> >> >> 2a) there must either be a SHACL vocabulary element that allows >> scoping based on *any* component of a triple, or 2b) there must be a >> separate SHACL vocabulary element that allows scoping based on >> matching a predicate. >> >> >> as stated above, we first need to define what does it mean to have a >> predicate as a scope >> e.g. sh:scopePredicate rdfs:label >> >> to me something like this would intuitively translate to the following >> SHACL scopes >> sh:scopeNode rdfs:label >> sh:scopeProperty rdfs:label >> sh:scopeInverseProperty rdfs:label >> i.e. the actual predicate as a node as well as all the subjects / >> objects in the data graph that appear in a triple with rdfs:label as >> predicate >> is this what you have in mind as well? in that case we can discuss if we >> can create such a syntax shortcut >> >> Best, >> Dimitris >> >> >> >> [1] >> >> https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#section-rdf-graph >> >> >> >> >> >> >> -- >> 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 > > -- 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 Thursday, 14 July 2016 08:22:37 UTC