Re: $variables

Partially answering my own questions, SHACL has:

2.1.3 Property scopes (sh:scopeProperty)

A property scope for property $scopeProperty is defined as the set of 
subjects in the data graph that appear in a triple with $scopeProperty 
as a predicate.

(and An inverse property scope for property $scopeInverseProperty is 
defined as the set of objects in the data graph that appear in a triple 
with $scopeInverseProperty as a predicate.)

which allows one to scope on predicates. So if we conclude that 
scopeNode only identifies nodes as defined in RDF, then all is well, but 
my knowledge of SPARQL doesn't allow me to ascertain if this definition 
in 2.1.1 is limited to RDF nodes:

SPARQL DEFINITION

SELECT DISTINCT ?this
WHERE {
	BIND ($scopeNode AS ?this)
}

which is where this conversation began, because that was what I was 
asking in that email that I linked to in my last email.

kc

On 7/11/16 5:24 PM, Karen Coyle wrote:
>
>
> On 7/11/16 3:50 PM, Andy Seaborne wrote:
>> Section 1.1 already has a link to RDF term in RDF 1.1.
>>
>> (originally from https://www.w3.org/TR/sparql11-query/#defn_RDFTerm
>> which was adopted by RDF 1.1).
>>
>> "Node" is the role that an RDF term is used for - the subject/object
>> role (position) : standard graph theory of vertex/node, not an edge.
>>
>> The set of nodes is the set of RDF terms used in subject or object
>> position.
>>
>> (Blank node is a misnomer in "generalised RDF" :
>> https://www.w3.org/TR/rdf11-concepts/#section-generalized-rdf)
>>
>> Having SHACL-defined versions of terminology will only lead to comments
>> like "are they the same thing?".
>>
>> It might be useful to split the terminolgy into terminology that are
>> used from elsewhere, and terminology that is defined by this document,
>> including different styling.
>>
>> I would find it clearer if the URL for the definition when to the to the
>> definition title (ie. the id should be on the title text), not into the
>> body of the text If nothing else, clicking on a definition link then
>> puts the box in the right place, not top-truncated (Firefox and Chrome).
>>
>> Karen - do you have example of where "node" is used to include
>> predicates? I don't know my way round the spec but looking through it, I
>> don't see any but I only jumped around the doc for a while.
>
> It doesn't say that in the spec, but this is how I interpreted Holger's
> response here:[1]. If I'm interpreting that wrong, please let me know.
> However, if scopenode only applies to nodes, then I wonder how one can
> "scope" triples in which the term of interest is the predicate.
>
> kc
>
> [1]
> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jun/0125.html
>
>
>>
>>     Andy
>>
>>
>> On 11/07/16 22:58, Karen Coyle wrote:
>>> Andy, I also wondered about that. RDF term seems to be saying that any
>>> "thing" in a triple is an RDF term, Whereas "node" is a subject or an
>>> object. However, I don't hear "RDF term" used much so if we use it in
>>> SHACL then we will definitely need to define it in the SHACL document
>>> where it is used.
>>>
>>> kc
>>>
>>>
>>> On 7/11/16 1:29 PM, Andy Seaborne wrote:
>>>> Is this the right terminology:
>>>>
>>>> RDF 1.1 Concepts:
>>>>
>>>> https://www.w3.org/TR/rdf11-concepts/#h2_section-rdf-graph
>>>> [[
>>>> IRIs <https://www.w3.org/TR/rdf11-concepts/#dfn-iri>, literals
>>>> <https://www.w3.org/TR/rdf11-concepts/#dfn-literal> and blank nodes
>>>> <https://www.w3.org/TR/rdf11-concepts/#dfn-blank-node> are collectively
>>>> known as RDF terms.
>>>> ]]
>>>>
>>>>
>>>>
>>>> On 08/07/16 16:56, Karen Coyle wrote:
>>>>> "Any node in the data graph that is equal to/the same as/matches (pick
>>>>> one) the value of sh:nodescope in the SHACL graph is 'in scope'."
>>>>>
>>>>> That said, the RDF Concepts document[1] describes a triple as two
>>>>> nodes (" node-arc-node "). Therefore "node" does not include the
>>>>> predicate of a triple. Could someone confirm that is the case?
>>>>>
>>>>> kc
>>>>> [1] https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/
>>>>>
>>>>> On 7/8/16 8:11 AM, Arnaud Le Hors wrote:
>>>>>> Ok, but this isn't just a matter of hiding this when SPARQL is
>>>>>> hidden. I
>>>>>> still want to understand what that sentence means when SPARQL isn't
>>>>>> hiddene. So, can you tell me what this sentence is supposed to be
>>>>>> saying?
>>>>>>
>>>>>> A node scope with value $scopeNode, defines $scopeNode as the node
>>>>>> in-scope in the data graph.
>>>>>>
>>>>>> The way it reads to me is that a node scope has a variable
>>>>>> $scopeNode as
>>>>>> a value, and that this defines the variable as the "node in-scope".
>>>>>> What
>>>>>> does it mean for a scope node to have a value? And How does a node
>>>>>> scope
>>>>>> with a value define the value as the "node in-scope"? And shouldn't
>>>>>> that
>>>>>> rather be "node in scope"??
>>>>>>
>>>>>> As I said I just can't parse this sentence. I'd appreciate if someone
>>>>>> could rephrase.
>>>>>>
>>>>>> Unfortunately the spec remains hard to read and understand because of
>>>>>> stuff like this so I second the sentiment Karen conveys from the
>>>>>> community she represents. I understand English isn't the editors'
>>>>>> primary language and that's ok but given that I strongly encourage
>>>>>> them
>>>>>> to welcome comments pointing these problems out.
>>>>>>
>>>>>> Thanks.
>>>>>> --
>>>>>> Arnaud  Le Hors - Senior Technical Staff Member, Open Web
>>>>>> Technologies -
>>>>>> IBM Cloud
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From:        Dimitris Kontokostas
>>>>>> <kontokostas@informatik.uni-leipzig.de>
>>>>>> To:        Arnaud Le Hors/Cupertino/IBM@IBMUS
>>>>>> Cc:        Karen Coyle <kcoyle@kcoyle.net>, public-data-shapes-wg
>>>>>> <public-data-shapes-wg@w3.org>
>>>>>> Date:        07/08/2016 01:38 AM
>>>>>> Subject:        Re: $variables
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> You are right,
>>>>>> although the button exists we the spec does not flow well in some
>>>>>> cases
>>>>>> when the sparql definitions are hidden
>>>>>> Holger created an issue to track this and we will try to have it
>>>>>> ready
>>>>>> for review by the next call
>>>>>>
>>>>>> On Fri, Jul 8, 2016 at 8:09 AM, Arnaud Le Hors <_lehors@us.ibm.com_
>>>>>> <mailto:lehors@us.ibm.com>> wrote:
>>>>>> I have to agree with Karen. In fact, I will admit that I don't
>>>>>> understand what this sentence means:
>>>>>>
>>>>>> A node scope with value $scopeNode, defines $scopeNode as the node
>>>>>> in-scope in the data graph.
>>>>>>
>>>>>> Actually, I can't even quite parse this sentence. What's with that
>>>>>> comma? What's the subject of "defines"?
>>>>>>
>>>>>> I do understand the following:
>>>>>>
>>>>>> Node scopes are defined with the sh:scopeNode predicate. The
>>>>>> values of
>>>>>> sh:scopeNode can be a IRIs or literals.
>>>>>>
>>>>>> Although the "a" seems to be a typo.
>>>>>> --
>>>>>> Arnaud  Le Hors - Senior Technical Staff Member, Open Web
>>>>>> Technologies -
>>>>>> IBM Cloud
>>>>>>
>>>>>>
>>>>>> Karen Coyle <_kcoyle@kcoyle.net_ <mailto:kcoyle@kcoyle.net>> wrote on
>>>>>> 07/07/2016 08:52:00 PM:
>>>>>>
>>>>>>> From: Karen Coyle <_kcoyle@kcoyle.net_ <mailto:kcoyle@kcoyle.net>>
>>>>>>> To: _public-data-shapes-wg@w3.org_
>>>>>>> <mailto:public-data-shapes-wg@w3.org>
>>>>>>> Date: 07/07/2016 08:53 PM
>>>>>>> Subject: Re: $variables
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 7/7/16 4:59 PM, Holger Knublauch wrote:
>>>>>>> >
>>>>>>> >
>>>>>>> > On 8/07/2016 9:45, Karen Coyle wrote:
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> On 7/7/16 3:42 PM, Holger Knublauch wrote:
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> On 8/07/2016 8:35, Karen Coyle wrote:
>>>>>>> >>>> On the call today I was told that the way to avoid the
>>>>>> complication of
>>>>>>> >>>> the $variables in the spec is to choose not to view the SPARQL
>>>>>>> in the
>>>>>>> >>>> draft. However, even with the SPARQL hidden, the $variables are
>>>>>>> still
>>>>>>> >>>> visible since they are part of the explanatory text. So this
>>>>>>> does not
>>>>>>> >>>> solve the problem, and in fact it probably makes it worse
>>>>>>> because
>>>>>>> >>>> without the SPARQL the $variables make even less sense. For
>>>>>>> example,
>>>>>>> >>>> with SPARQL definitions hidden, you see:
>>>>>>> >>>>
>>>>>>> >>>> **********
>>>>>>> >>>>
>>>>>>> >>>> 2.1.1 Node scopes (sh:scopeNode)
>>>>>>> >>>>
>>>>>>> >>>> A node scope with value $scopeNode, defines $scopeNode as the
>>>>>>> node
>>>>>>> >>>> in-scope in the data graph.
>>>>>>> >>>>
>>>>>>> >>>> Node scopes are defined with the sh:scopeNode predicate. The
>>>>>> values of
>>>>>>> >>>> sh:scopeNode can be a IRIs or literals.
>>>>>>> >>>>
>>>>>>> >>>> *************
>>>>>>> >>>>
>>>>>>> >>>> I think they need to be removed from the text, and moved into
>>>>>>> the
>>>>>>> >>>> SPARQL code area, and the text should be complete without using
>>>>>>> them.
>>>>>>> >>>
>>>>>>> >>> That would be fine with me. I had used the values in
>>>>>>> SPARQL-like $
>>>>>>> >>> notation to make it easier to read for those who are familiar
>>>>>>> with
>>>>>>> >>> SPARQL because the SPARQL query and its description would match.
>>>>>> But if
>>>>>>> >>> the WG thinks this is too geeky, we can just drop the $ sign and
>>>>>> change
>>>>>>> >>> the CSS style around these variables.
>>>>>>> >>>
>>>>>>> >>> I do wonder what audience are we talking about here? What in
>>>>>> particular
>>>>>>> >>> is difficult to understand about the $ variables? The spec is
>>>>>>> not a
>>>>>>> >>> tutorial...
>>>>>>> >>>
>>>>>>> >>> Holger
>>>>>>> >>
>>>>>>> >> Holger, you always trot out this "not a tutorial" like anyone who
>>>>>>> has
>>>>>>> >> any problem with the spec is some kind of backward dunce. I
>>>>>>> wish you
>>>>>>> >> would be less condescending and more open to hearing suggestions.
>>>>>>> The
>>>>>>> >> folks who brought this up are key RDF programmers on projects
>>>>>>> like
>>>>>>> >> Europeana and DPLA. Hardly novices. But believe them when they
>>>>>>> say
>>>>>>> >> that it makes the reading and comprehension more difficult. Do
>>>>>>> not
>>>>>>> >> disparage them.
>>>>>>> >
>>>>>>> > The suggested change here is to drop the $ character before
>>>>>>> variable
>>>>>>> > names in the scope section. I am really surprised this would
>>>>>>> make a
>>>>>>> > difference, but said I have no problems with that.
>>>>>>>
>>>>>>> I'm pretty sure it isn't just a matter of dropping the $ - it
>>>>>>> doesn't
>>>>>>> make sense to say:
>>>>>>>
>>>>>>> "A node scope with value scopeNode, defines scopeNode as the node
>>>>>>> in-scope in the data graph."
>>>>>>>
>>>>>>> So some more adjustment of the text is going to be needed.
>>>>>>> Especially
>>>>>>> because there is sometimes more about SPARQL in the text, such as:
>>>>>>>
>>>>>>> *********
>>>>>>> 2.1.1 Node scopes (sh:scopeNode)
>>>>>>>
>>>>>>> A node scope with value $scopeNode, defines $scopeNode as the node
>>>>>>> in-scope in the data graph.
>>>>>>>
>>>>>>> Node scopes are defined with the sh:scopeNode predicate. The
>>>>>>> values of
>>>>>>> sh:scopeNode can be a IRIs or literals.
>>>>>>>
>>>>>>> The following SPARQL query specifies the semantics of node scopes.
>>>>>>> The
>>>>>>> variable $scopeNode is assumed to be pre-bound to the given value of
>>>>>>> sh:scopeNode.
>>>>>>>
>>>>>>> *******
>>>>>>>
>>>>>>> It doesn't make sense to say "The following SPARQL query...." when
>>>>>>> the
>>>>>>> SPARQL query is hidden.
>>>>>>>
>>>>>>> If we can agree on parameters of the edits, I'd be happy to pitch
>>>>>>> in a
>>>>>>> do some or all of the work. I'd say that the last paragraph belongs
>>>>>>> with
>>>>>>> the SPARQL code, and the first sentence needs a different value
>>>>>>> example,
>>>>>>> which should be uniform throughout where possible.
>>>>>>>
>>>>>>> I'd also reverse the first two paragraphs, which I think increases
>>>>>>> readability.
>>>>>>>
>>>>>>> kc
>>>>>>>
>>>>>>> >
>>>>>>> > What else would be needed to make the document more readable for
>>>>>>> the
>>>>>>> > audience you are referring to?
>>>>>>> >
>>>>>>> > Anyway, I think you are over-reacting in your personal criticism.
>>>>>>> I am
>>>>>>> > merely collecting information to help me fulfill my editing role.
>>>>>>> If I
>>>>>>> > were to accept every single viewpoint without asking for
>>>>>>> clarifications
>>>>>>> > we would never reach a fixpoint - there are just too many
>>>>>>> different
>>>>>>> > viewpoints and potential audiences here.
>>>>>>> >
>>>>>>> > Holger
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>> --
>>>>>>> Karen Coyle
>>>>>>> _kcoyle@kcoyle.net_ <mailto:kcoyle@kcoyle.net>_http://kcoyle.net_
>>>>>> <http://kcoyle.net/>
>>>>>>> m: 1-510-435-8234
>>>>>>> skype: kcoylenet/_+1-510-984-3600_ <tel:%2B1-510-984-3600>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dimitris Kontokostas
>>>>>> Department of Computer Science, University of Leipzig & DBpedia
>>>>>> Association
>>>>>> Projects: _http://dbpedia.org_ <http://dbpedia.org/>,
>>>>>> _http://rdfunit.aksw.org_ <http://rdfunit.aksw.org/>,
>>>>>> _http://aligned-project.eu_ <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, 12 July 2016 00:52:59 UTC