- From: Irene Polikoff <irene@topquadrant.com>
- Date: Wed, 7 Dec 2016 16:09:25 -0500
- To: kcoyle@kcoyle.net
- Cc: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
Karen, I hear that you are frustrated and I feel for you. At times, it has been a very frustrating experience for me as well. It is easy to get into rabbit holes and confusion when one uses e-mails. It is also easy to loose a lot of time to try to understand what someone says. Interpreting it incorrectly is often a very real possibility and this has a consequence of loosing more time, getting annoyed with a person because you misunderstood them, getting the person annoyed with you because you misunderstood them and so on. All of this is indeed frustrating. The only way I know how to handle this is to tell my self to “pop up” a level. It is easy to interpret everything negatively, imagine differences where none exist and make small differences appear larger than life. I also loose a lot of time trying to understand what people on the mailing list say. For example, did you, in your message, mistook rdf:_2 as a resource? That was my first guess. However, even if it was a blank node what difference would it make? Let’s say it was :_x rdfs:domain rdfs:Resource. So, what? What does it have to do with our discussion? This is just one example that was at least short. Many times people send very complex and cryptic messages that are hard to understand and very easy to misinterpret. I suspect that you and I are fairly often interpreting the same e-mails in different ways. There must be some best practices for improving this. Talking helps. Coming back to resources, I use the word “resource” all the time. As you say, it makes sense to people. I am sure Holger has absolutely nothing against this word either. The main issue, I believe, is that he is trying to ensure that the spec is correct formally - so that the spec is not overly criticized for not adhering to the formal definitions. And there has been a lot of criticism in that area. The way “resource” is used colloquially in practice is subtly different from the formal definition. Some people jump on the subtle differences that make no practical difference and make them look like big issues. Formally speaking, what Jan said (and I hope Jan will not get upset at me for saying this) was “incorrect”: >>>>>> To be even more precise: a shape is a resource and can be >>>>>> referred to by means of an IRI or a blank node. Literals do not refer >>>>>> to resources. -j Again, formally, we can’t say that a blank node refers to a resource. As I painstakingly described in my e-mail, a blank node can identify that a resource exists and can be used to describe it, but it doesn’t name it or refers to it. And literals are another matter, so lets not go into that. Because of the choice of words his sentence couldn’t be just dropped into the spec as-is. The sentence you proposed: >>>>> Shape is a resource that it is referred to *by means of an IRI*. Could potentially be put into the spec. However, while there is nothing incorrect here, it doesn’t say anything. Everything except for literals is referred/denoted/named using an IRI. Some people may criticize it on that ground. And since this sentence doesn’t really say anything, by itself, it doesn’t address the topic of this thread which was “what is a shape” and how to improve its definition in the spec? What is your view of the definition I proposed? Do you see any issues with it and, if so, what are they? Irene > On Dec 7, 2016, at 3:11 PM, Karen Coyle <kcoyle@kcoyle.net> wrote: > > Right, I mistook that for a blank node. However, I have been told by unnamed others, and of course this began with a useful suggestion by Jan Voskuil, that blank nodes are indeed referred to as resources, albeit unnamed - as Irene points out below. Yet when I suggested that we use the term "resource" because it makes sense to people, I was told in no uncertain terms by Holger that a blank node cannot be a resource so we cannot use that term. > > I'm giving up on this. All I get is very definite "no" to suggestions I make that endeavor to make this document more readable. I do not feel that my community's needs are being met in this standards process because of this continuous push-back against even editorial changes. It has become a waste of my time. > > kc > > On 12/7/16 11:42 AM, Irene Polikoff wrote: >> I am also not sure what Karen is pointing out. rdf:_2 is not a blank >> node. Karen, can you please clarify? >> >> The relevant (to this exchange) part of RDF 1.1 Concepts and Abstract >> Syntax, section 1.2 is: >> >> Unlike IRIs <https://www.w3.org/TR/rdf11-concepts/#dfn-iri> and >> literals <https://www.w3.org/TR/rdf11-concepts/#dfn-literal>, blank >> nodes <https://www.w3.org/TR/rdf11-concepts/#dfn-blank-node> do not >> identify specific resources >> <https://www.w3.org/TR/rdf11-concepts/#dfn-resource>. Statements >> <https://www.w3.org/TR/rdf11-concepts/#dfn-rdf-statement> involving >> blank nodes say that something with the given relationships exists, >> without explicitly naming it. >> >> A blank node indicates that a resource that fits the description exists >> without naming it. There may be more than one. Thus, a blank node can >> be used to say that a shape exists and describe it without naming it. >> >> A URI indicates one resource exists and names it. >> >> Formally speaking: >> >> * A shape is an abstract concept (in the domain of discourse, which in >> RDF is everything, including RDF). >> * An RDF Term refers (denotes, names) a shape. If it is a URI it is >> because that URI is defined to be a shape - that information is not >> in the graph. >> * Because it is an abstract concept, it is not a literal. Literals >> denote values (datatype). Actually, they self-denote which is what >> makes them literals. >> >> So far, there are no triples and no graphs. This is all about naming or >> denoting things. A URI refers to a shape because the creator of the URI >> says it does. >> >> From there we can go into triples: >> >> It may be useful to add >> >> <x> a shacl:Shape . >> >> because that makes the information explicit in the graph. We now have a >> graph that describes a shape. The graph is not a shape. It is a graph of >> RDF Terms and a triple. Graphs describes (as in "Resource Description >> Format") a shape in its various aspects. There are other ways of knowing >> a term denotes a shape other than "a shacl:Shape". e.g. rdfs:domain of a >> property. >> >> We could say that a shape is a resource that is denoted by an RDF Term. >> I see no problem with this, but it would be like saying nothing. RDF >> Terms denote. That's all they do. >> >> I propose a definition along these lines: >> >> A shape describes a set of conditions the structure of an RDF graph >> must meet. By structure we mean what triples can and can not be a >> part of a graph. A shape has a scope of applicability. By scope of >> applicability we mean what subgraphs in an RDF data graph are >> expected to conform to a shape. >> >> A shapes graph is a set of triples describing zero or more shapes. >> >> (A graph is a shapes graph if it is used as one. Any graph could be >> that - nothing much happens if there are no shapes.) >> >> Data graph is any set of triples that is tested for conformance to >> the shapes in the shapes graph. >> >> (This could be any graph including a graph that describes shapes. It >> is the fact of it being tested that makes it a data graph.) >> >> What makes a graph the “shapes graph” or the "data graph" are their >> roles in the process, not their content. >> >> A SHACL processor finds shapes in a graph by looking for nodes that >> meet one of the following criteria: >> >> · the node is a SHACL instance >> <http://w3c.github.io/data-shapes/shacl/#dfn-shacl-instance> of >> sh:Shape or >> >> · the node has the expected type >> <http://w3c.github.io/data-shapes/shacl/#dfn-expected-type> >> sh:Shape, which is the case if it is used as a value of >> shape-expecting constraint parameters >> <http://w3c.github.io/data-shapes/shacl/#dfn-shape-expecting-constraint-parameters> >> such as sh:shape (in the case of the list-valued parameters >> sh:and, sh:or and sh:partition it is a member >> <http://w3c.github.io/data-shapes/shacl/#dfn-members> of the >> corresponding lists) or >> >> · the node has a value >> <http://w3c.github.io/data-shapes/shacl/#dfn-values> for any of >> the target <http://w3c.github.io/data-shapes/shacl/#dfn-target> >> properties sh:targetClass, sh:targetNode, sh:targetObjectsOf, >> sh:targetSubjectsOf and sh:target >> >> >> (I am using the above bullets as-is in the spec, but they could and >> probably should be further cleaned up.) >> >> >> Irene >> >>> On Dec 6, 2016, at 10:09 PM, Karen Coyle <kcoyle@kcoyle.net >>> <mailto:kcoyle@kcoyle.net>> wrote: >>> >>> RDF 1.1 Semantics, section 9, valid triples: >>> >>> rdf:_2 rdfs:domain rdfs:Resource . >>> rdf:_2 rdfs:range rdfs:Resource . >>> >>> kc >>> >>> On 12/5/16 4:15 PM, Holger Knublauch wrote: >>>> RDF 1.1 Concepts and Abstract Syntax, section 1.2: >>>> >>>> Any IRI <https://www.w3.org/TR/rdf11-concepts/#dfn-iri> or literal >>>> <https://www.w3.org/TR/rdf11-concepts/#dfn-literal> denotes something in >>>> the world (the "universe of discourse"). These things are called >>>> resources. >>>> >>>> This states that literals *can* refer to resources but blank nodes can >>>> not. Shapes can be represented by blank nodes in SHACL. >>>> >>>> What practical value does the term "resource" add? We are defining a >>>> syntax (vocabulary) which is parsed by a machine. Of course humans are >>>> free to link these syntactic structures to some real-world entity (such >>>> as the concept of a shape) in our heads. Different people will have >>>> different mental pictures of what this entity could be for them, and >>>> that's a good topic for tutorials, but is IMHO not necessary to >>>> formalize the algorithms for the machines. >>>> >>>> Holger >>>> >>>> >>>> On 6/12/2016 1:38, Karen Coyle wrote: >>>>> I like the wording that it is a resource (not just a node or an IRI), >>>>> and that it is referred to *by means of an IRI*. That is much clearer >>>>> and corresponds to how it is used in the spec. >>>>> >>>>> kc >>>>> >>>>> On 12/2/16 12:29 AM, Jan Voskuil wrote: >>>>>> I agree. To be even more precise: a shape is a resource and can be >>>>>> referred to by means of an IRI or a blank node. Literals do not refer >>>>>> to resources. -j >>>>>> >>>>>> -----Original Message----- >>>>>> From: Irene Polikoff [mailto:irene@topquadrant.com] >>>>>> Sent: 02 December 2016 03:25 >>>>>> To: kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> >>>>>> Cc: public-data-shapes-wg@w3.org <mailto:public-data-shapes-wg@w3.org> >>>>>> Subject: Re: shapes-ISSUE-209 (What is a shape?): What is a shape >>>>>> [SHACL Spec] >>>>>> >>>>>> Shapes can be subjects and objects of triples. A shape can't be a >>>>>> literal. >>>>>> >>>>>> If it helps, the spec could say that a shape is either an IRI or an >>>>>> anonymous node. >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Dec 1, 2016, at 2:27 PM, Karen Coyle <kcoyle@kcoyle.net >>>>>>> <mailto:kcoyle@kcoyle.net>> wrote: >>>>>>> >>>>>>> Uh, yes. But the question is about how shape is defined in SHACL, >>>>>>> not what node means in RDF. When the document says "a shape is a >>>>>>> node" is it defining a shape as either a subject, predicate or >>>>>>> object? and does that also mean that a shape can be a literal? >>>>>>> Because all of those are possible with the RDF definition of node. >>>>>>> >>>>>>> kc >>>>>>> >>>>>>>> On 12/1/16 10:20 AM, Irene Polikoff wrote: >>>>>>>> A node can participate in multiple triples and play a different >>>>>>>> role in different triples, yet it is the same node and it can be >>>>>>>> talked about simply as a node in a graph. Talking about a node as a >>>>>>>> subject, object or a predicate makes sense only in a context of a >>>>>>>> specific triple. >>>>>>>> >>>>>>>>> On Dec 1, 2016, at 12:33 PM, Karen Coyle <kcoyle@kcoyle.net >>>>>>>>> <mailto:kcoyle@kcoyle.net>> wrote: >>>>>>>>> >>>>>>>>> One more thing - a node can be a subject, predicate or object. >>>>>>>>> Would a node in predicate or object position define a shape? Can a >>>>>>>>> shape be a literal? >>>>>>>>> >>>>>>>>> Peter pointed this out in an earlier email, which I am still >>>>>>>>> searching for. >>>>>>>>> >>>>>>>>> kc >>>>>>>>> >>>>>>>>>> On 11/28/16 9:04 AM, Karen Coyle wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 11/27/16 4:28 PM, Holger Knublauch wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 28/11/2016 8:33, Karen Coyle wrote: >>>>>>>>>>>> There is a simple solution to this, and it follows in part the >>>>>>>>>>>> example of the Annotations Working Group. Their spec defines a : >>>>>>>>>>>> >>>>>>>>>>>> *** >>>>>>>>>>>> An Annotation is a rooted, directed graph that represents a >>>>>>>>>>>> relationship between resources. >>>>>>>>>>>> There are two primary types of resource that participate in this >>>>>>>>>>>> relationship, Bodies and Targets. >>>>>>>>>>>> Annotations have 0 or more Bodies. >>>>>>>>>>>> Annotations have 1 or more Targets. >>>>>>>>>>>> **** >>>>>>>>>>>> >>>>>>>>>>>> All that needs to be done is to define "shape" as a graph whose >>>>>>>>>>>> root is a subject is of type sh:Shape, and has 0 or more targets >>>>>>>>>>>> and 1 or more constraints. >>>>>>>>>>> >>>>>>>>>>> This would not be correct. A shape doesn't need one or more >>>>>>>>>>> constraints. >>>>>>>>>>> sh:Shape is a subclass of sh:Constraint (which makes every shape >>>>>>>>>>> automatically also a constraint), but this doesn't "do" anything >>>>>>>>>>> by itself. Also the zero or more doesn't add anything. (Shapes may >>>>>>>>>>> also have labels etc). >>>>>>>>>> >>>>>>>>>> So drop the zero or more, but the spec itself says that shapes have >>>>>>>>>> constraints: >>>>>>>>>> >>>>>>>>>> "property constraints of the shape" (3.1.1) >>>>>>>>>> >>>>>>>>>> Anyway, I'll take this to DCMI leadership. At this point, I can >>>>>>>>>> only say that our needs are not being met. >>>>>>>>>> >>>>>>>>>> kc >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As always, the more complexity we are adding here, someone will >>>>>>>>>>> find problems with it. And pointing out issues is trivial compared >>>>>>>>>>> to getting everything right. That's why I would leave out anything >>>>>>>>>>> that isn't formally needed. We can leave such explanatory prose to >>>>>>>>>>> other documents, and if these other documents prefer to understand >>>>>>>>>>> a shape as a collection of specific triples then fine. >>>>>>>>>>> >>>>>>>>>>> Holger >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Really, that's all that is needed. >>>>>>>>>>>> >>>>>>>>>>>> kc >>>>>>>>>>>> p.s. I like the idea of the shape having a "root" node. I'm not >>>>>>>>>>>> sure if something needs to be said about targets, which are also >>>>>>>>>>>> of sh:Shape - is it necessary to say that they are not what is >>>>>>>>>>>> meant when the spec talks about "shapes"? >>>>>>>>>>>> >>>>>>>>>>>>> On 11/27/16 7:16 AM, Karen Coyle wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/26/16 3:08 PM, Holger Knublauch wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 25/11/2016 5:41, Irene Polikoff wrote: >>>>>>>>>>>>>>> I took the initial question to be "when is a resource (or a >>>>>>>>>>>>>>> node) a shape?". And not to be "what are all the triples that >>>>>>>>>>>>>>> describe a shape?". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To me, these are two completely different questions. >>>>>>>>>>>>>>> Colloquially speaking, shape may be said to be a set of >>>>>>>>>>>>>>> triples. But writing a spec requires us to be precise. And >>>>>>>>>>>>>>> precisely speaking, shape is not a set of triples, it is a >>>>>>>>>>>>>>> node. Information about it is described/specified/defined >>>>>>>>>>>>>>> using a set of triples. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thus, I would recommend closing the first question as >>>>>>>>>>>>>>> resolved. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As for the second question, why does it need to be answered? A >>>>>>>>>>>>>>> more meaningful question may be "when is a shape graph >>>>>>>>>>>>>>> sufficiently complete to be able to process it and what should >>>>>>>>>>>>>>> a SHACL processor do when a shapes graph doesn't have all the >>>>>>>>>>>>>>> necessary information"? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For example, let's say a shapes graph contains only the >>>>>>>>>>>>>>> following >>>>>>>>>>>>>>> triples: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ex:PersonShape >>>>>>>>>>>>>>> a sh:Shape ; >>>>>>>>>>>>>>> sh:targetClass ex:Person ; >>>>>>>>>>>>>>> sh:property [ >>>>>>>>>>>>>>> sh:predicate ex:worksFor; >>>>>>>>>>>>>>> sh:shape ex:OrganizationShape; ]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This, to me, would be insufficient to do anything with since >>>>>>>>>>>>>>> to validate data against it, we need to have a description of >>>>>>>>>>>>>>> ex:OrganizationShape. What should happen in such cases? >>>>>>>>>>>>>> >>>>>>>>>>>>>> This case is covered by the spec. It's simply a shape without >>>>>>>>>>>>>> constraints, i.e. every node conforms to it. Yet it's >>>>>>>>>>>>>> syntactically valid because the expected type of sh:shape is >>>>>>>>>>>>>> sh:Shape. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Other examples mentioned by Karen: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ex:ExampleShapeWithPropertyConstraints >>>>>>>>>>>>>>> a sh:Shape ; >>>>>>>>>>>>>>> sh:property [ >>>>>>>>>>>>>>> sh:predicate ex:email ; >>>>>>>>>>>>>>> sh:name "e-mail" ; >>>>>>>>>>>>>>> sh:description "We need at least one email >>>>>>>>>>>>>>> value" ; >>>>>>>>>>>>>>> sh:minCount 1 ; >>>>>>>>>>>>>>> ] ; >>>>>>>>>>>>>>> sh:property [ >>>>>>>>>>>>>>> sh:path (ex:knows ex:email) ; >>>>>>>>>>>>>>> sh:name "Friend's e-mail" ; >>>>>>>>>>>>>>> sh:description "We need at least one email for >>>>>>>>>>>>>>> everyone you know" ; >>>>>>>>>>>>>>> sh:minCount 1 ; >>>>>>>>>>>>>>> ] . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is only one shape - >>>>>>>>>>>>>>> ex:ExampleShapeWithPropertyConstraints. If this is all the >>>>>>>>>>>>>>> content of a shapes graph, it is fine. All the information >>>>>>>>>>>>>>> needed for validation is here. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ex:MyShape >>>>>>>>>>>>>>> a sh:Shape ; >>>>>>>>>>>>>>> sh:targetNode ex:MyInstance ; >>>>>>>>>>>>>>> sh:property [ >>>>>>>>>>>>>>> # Violations of sh:minCount and sh:datatype are >>>>>>>>>>>>>>> produced as warnings >>>>>>>>>>>>>>> sh:predicate ex:myProperty ; >>>>>>>>>>>>>>> sh:minCount 1 ; >>>>>>>>>>>>>>> sh:datatype xsd:string ; >>>>>>>>>>>>>>> sh:severity sh:Warning ; >>>>>>>>>>>>>>> ] ; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One shape - ex:MyShape. It refers to a target node. Target >>>>>>>>>>>>>>> node is not a shape, it identifies a node in a data graph that >>>>>>>>>>>>>>> is to be validated against a shape, so I am not sure what is >>>>>>>>>>>>>>> the question. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ex:PersonShape >>>>>>>>>>>>>>> a sh:Shape ; >>>>>>>>>>>>>>> sh:targetClass ex:Person ; >>>>>>>>>>>>>>> sh:property ex:PersonShape-name . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ex:PersonShape-name >>>>>>>>>>>>>>> a sh:PropertyConstraint ; >>>>>>>>>>>>>>> sh:predicate ex:name ; >>>>>>>>>>>>>>> sh:minCount 1 ; >>>>>>>>>>>>>>> sh:deactivated true . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is only one shape - ex:PersonShape. All the information >>>>>>>>>>>>>>> necessary for validation is present and, in fact, there would >>>>>>>>>>>>>>> be automatic conformance since the only constraint is >>>>>>>>>>>>>>> disabled. However, if a shapes graph only contained the >>>>>>>>>>>>>>> following, validation would not be possible (I think): >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ex:PersonShape >>>>>>>>>>>>>>> a sh:Shape ; >>>>>>>>>>>>>>> sh:targetClass ex:Person ; >>>>>>>>>>>>>>> sh:property ex:PersonShape-name . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, again, what should happen in these cases? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> All the examples above are for a single shape. In some of the >>>>>>>>>>>>>>> examples information about it is complete enough to validate >>>>>>>>>>>>>>> data against the shape. In others, it is not. We should also >>>>>>>>>>>>>>> consider the fact that a shapes graph can and often will >>>>>>>>>>>>>>> contain multiple shapes and some shapes may have sufficient >>>>>>>>>>>>>>> description to validate against and others may not. Also, some >>>>>>>>>>>>>>> shapes may have some information that can be checked and some >>>>>>>>>>>>>>> that can't be. For example, given the shape graph below we >>>>>>>>>>>>>>> would know enough to check conformance of values of ex:email, >>>>>>>>>>>>>>> but not know enough to check values of ex:worksFor. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ex:PersonShape >>>>>>>>>>>>>>> a sh:Shape ; >>>>>>>>>>>>>>> sh:targetClass ex:Person ; >>>>>>>>>>>>>>> sh:property [ >>>>>>>>>>>>>>> sh:predicate ex:worksFor; >>>>>>>>>>>>>>> sh:shape ex:OrganizationShape; ]; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> sh:property [ >>>>>>>>>>>>>>> sh:path (ex:knows ex:email) ; >>>>>>>>>>>>>>> sh:name "Friend's e-mail" ; >>>>>>>>>>>>>>> sh:description "We need at least one email for >>>>>>>>>>>>>>> everyone you know" ; >>>>>>>>>>>>>>> sh:minCount 1 ; >>>>>>>>>>>>>>> ] . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So, one proposal may be as follows: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If a shapes graph contains any shapes that are insufficiently >>>>>>>>>>>>>>> specified, processing doesn't happen and SHACL engine returns >>>>>>>>>>>>>>> an error. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The spec mentions several conditions under which a shapes graph >>>>>>>>>>>>>> is invalid. These are typically written as "a shape must ...". >>>>>>>>>>>>>> >>>>>>>>>>>>>> On the more general topic of node vs triples, I find this >>>>>>>>>>>>>> rather philosophical. The spec is pretty clear about what >>>>>>>>>>>>>> happens in each context. Which triples "belong" to a shape is >>>>>>>>>>>>>> following from that, but not valuable on its own right. >>>>>>>>>>>>> >>>>>>>>>>>>> The spec is not "pretty clear" and this is not "philosophical" - >>>>>>>>>>>>> it has to be clear *to all* what is being described in the spec. >>>>>>>>>>>>> Insisting that the spec is ok when others are saying it is not >>>>>>>>>>>>> is one of the things that is making the progress very slow. It >>>>>>>>>>>>> is incredibly generous of people to be putting time into trying >>>>>>>>>>>>> to make it actually clear, but, personally, I'm running out of >>>>>>>>>>>>> steam. However, note that DCMI will not approve a highly flawed >>>>>>>>>>>>> spec. >>>>>>>>>>>>> >>>>>>>>>>>>> kc >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Holger >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Another proposal may be: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Data is processed against shapes that are sufficiently >>>>>>>>>>>>>>> specified. >>>>>>>>>>>>>>> Warning is issued regarding shapes that are insufficiently >>>>>>>>>>>>>>> specified and, thus, ignored. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yet another proposal may be: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Data is processed against shapes that are sufficiently >>>>>>>>>>>>>>> specified. >>>>>>>>>>>>>>> Warning is issued regarding shapes that are insufficiently >>>>>>>>>>>>>>> specified. >>>>>>>>>>>>>>> SHACL processor will perform as much validation as it able to >>>>>>>>>>>>>>> against insufficiently specified shapes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Of course, we would need to define what it means to be >>>>>>>>>>>>>>> "insufficiently specified". >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Thu, Nov 24, 2016 at 12:29 PM, Karen Coyle >>>>>>>>>>>>>>> <kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> >>>>>>>>>>>>>>> <mailto:kcoyle@kcoyle.net>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Actually, I don't think this solves the problem that came up >>>>>>>>>>>>>>> at the meeting. As we discussed in the meeting, the conflict >>>>>>>>>>>>>>> is between a node, which is a single IRI, and a graph, which >>>>>>>>>>>>>>> is a set of triples. Throughout the document, the term >>>>>>>>>>>>>>> "shape" is used to refer to more than a single IRI. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The statement below could be used for how a shape is >>>>>>>>>>>>>>> identified (although I think we should discuss that further) >>>>>>>>>>>>>>> but does not define how one finds the finite boundaries of >>>>>>>>>>>>>>> the set of triples that is used as an instrument to define >>>>>>>>>>>>>>> the validation rules that will be applied to a data graph. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Something that was said in the meeting made me think that >>>>>>>>>>>>>>> defining where a shape ends is as important as defining where >>>>>>>>>>>>>>> it begins. >>>>>>>>>>>>>>> (Note that in this case I am speaking of a shape as a set of >>>>>>>>>>>>>>> triples, not a node - we know where a node ends, because it is >>>>>>>>>>>>>>> a single point.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In an example like this (taken from the spec), I assume that >>>>>>>>>>>>>>> this represents a single shape: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ex:ExampleShapeWithPropertyConstraints >>>>>>>>>>>>>>> a sh:Shape ; >>>>>>>>>>>>>>> sh:property [ >>>>>>>>>>>>>>> sh:predicate ex:email ; >>>>>>>>>>>>>>> sh:name "e-mail" ; >>>>>>>>>>>>>>> sh:description "We need at least one email >>>>>>>>>>>>>>> value" ; >>>>>>>>>>>>>>> sh:minCount 1 ; >>>>>>>>>>>>>>> ] ; >>>>>>>>>>>>>>> sh:property [ >>>>>>>>>>>>>>> sh:path (ex:knows ex:email) ; >>>>>>>>>>>>>>> sh:name "Friend's e-mail" ; >>>>>>>>>>>>>>> sh:description "We need at least one email >>>>>>>>>>>>>>> for everyone you know" ; >>>>>>>>>>>>>>> sh:minCount 1 ; >>>>>>>>>>>>>>> ] . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Where there is a target, which is also a shape, is this one >>>>>>>>>>>>>>> or two shapes? And if two, what are the boundaries of each? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ex:MyShape >>>>>>>>>>>>>>> a sh:Shape ; >>>>>>>>>>>>>>> sh:targetNode ex:MyInstance ; >>>>>>>>>>>>>>> sh:property [ >>>>>>>>>>>>>>> # Violations of sh:minCount and sh:datatype >>>>>>>>>>>>>>> are produced as warnings >>>>>>>>>>>>>>> sh:predicate ex:myProperty ; >>>>>>>>>>>>>>> sh:minCount 1 ; >>>>>>>>>>>>>>> sh:datatype xsd:string ; >>>>>>>>>>>>>>> sh:severity sh:Warning ; >>>>>>>>>>>>>>> ] ; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The following is an example of the case that I believe was >>>>>>>>>>>>>>> intended at the meeting. The question is whether this is one >>>>>>>>>>>>>>> shape or two? And if it is two, how is that distinguished >>>>>>>>>>>>>>> from the shape immediately above that has a target? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ex:PersonShape >>>>>>>>>>>>>>> a sh:Shape ; >>>>>>>>>>>>>>> sh:targetClass ex:Person ; >>>>>>>>>>>>>>> sh:property ex:PersonShape-name . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ex:PersonShape-name >>>>>>>>>>>>>>> a sh:PropertyConstraint ; >>>>>>>>>>>>>>> sh:predicate ex:name ; >>>>>>>>>>>>>>> sh:minCount 1 ; >>>>>>>>>>>>>>> sh:deactivated true . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If this seems petty, remember that throughout, the document >>>>>>>>>>>>>>> refers to a thing called "shape" and all of the understanding >>>>>>>>>>>>>>> of the document depends on the reader understanding exactly >>>>>>>>>>>>>>> what that means. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> kc >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/23/16 7:34 PM, Holger Knublauch wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Holger >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 24/11/2016 13:32, Irene Polikoff wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I suggest changing >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <A shape can be a node >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-n >>>>>>>>>>>>>>> ode >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-node>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> a shapes graph >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-s >>>>>>>>>>>>>>> hapes-graph >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-shapes-graph>>. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A node is a shape if and only if it fulfills either >>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>> following >>>>>>>>>>>>>>> conditions in the shapes graph:> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <A shape is a node >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-n >>>>>>>>>>>>>>> ode >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-node>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> a shapes graph >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-s >>>>>>>>>>>>>>> hapes-graph >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-s >>>>>>>>>>>>>>> hapes-graph>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> fulfills either of the following conditions: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Nov 23, 2016 at 7:48 PM, Holger Knublauch >>>>>>>>>>>>>>> <holger@topquadrant.com >>>>>>>>>>>>>>> <mailto:holger@topquadrant.com> >>>>>>>>>>>>>>> <mailto:holger@topquadrant.com> >>>>>>>>>>>>>>> <mailto:holger@topquadrant.com >>>>>>>>>>>>>>> <mailto:holger@topquadrant.com>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The current definition in 2.1 reads >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A shape can be a node >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-node> in >>>>>>>>>>>>>>> a shapes graph >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-shapes-graph> that is >>>>>>>>>>>>>>> a SHACL instance >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-shacl-instance> of >>>>>>>>>>>>>>> |sh:Shape|; or it >>>>>>>>>>>>>>> can be a node so that the expected type >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-expected-type> of the node >>>>>>>>>>>>>>> is |sh:Shape|, or a node that has a value >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-values> for a target >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-target> property such >>>>>>>>>>>>>>> as |sh:targetClass| in the shapes graph >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-shapes-graph>. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> These are all (3) ways of how shapes are >>>>>>>>>>>>>>> identified. I >>>>>>>>>>>>>>> have just >>>>>>>>>>>>>>> added some precision based on the newly >>>>>>>>>>>>>>> introduced term >>>>>>>>>>>>>>> shape-expecting constraint parameters, and >>>>>>>>>>>>>>> explicitly >>>>>>>>>>>>>>> enumerated >>>>>>>>>>>>>>> the target properties. The definition now reads >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A shape can be a node >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-node> in >>>>>>>>>>>>>>> a shapes graph >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-shapes-graph>. A node >>>>>>>>>>>>>>> is a shape if and only if it fulfills either of >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> following >>>>>>>>>>>>>>> conditions in the shapes graph: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * the node is a SHACL instance >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-shacl-instance> of >>>>>>>>>>>>>>> |sh:Shape| >>>>>>>>>>>>>>> * the node has the expected type >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-expected-type> >>>>>>>>>>>>>>> |sh:Shape|, which >>>>>>>>>>>>>>> is the case if it is used as a value of >>>>>>>>>>>>>>> shape-expecting >>>>>>>>>>>>>>> constraint parameters >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-shape-expecting-constraint-parameters> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> such >>>>>>>>>>>>>>> as |sh:shape| (in the case of the list-valued >>>>>>>>>>>>>>> parameters |sh:and|, |sh:or| and >>>>>>>>>>>>>>> |sh:partition| it >>>>>>>>>>>>>>> must be a >>>>>>>>>>>>>>> member of the corresponding lists) >>>>>>>>>>>>>>> * the node has a value >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-values> for >>>>>>>>>>>>>>> any of the target >>>>>>>>>>>>>>> <#m_1017120090268237992_dfn-target> properties >>>>>>>>>>>>>>> |sh:targetClass|, |sh:targetNode|, >>>>>>>>>>>>>>> |sh:targetObjectsOf|, >>>>>>>>>>>>>>> |sh:targetSubjectsOf| and |sh:target| >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Change: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954 >>>>>>>>>>>>>>> dbc38cf4e435861238a2 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://github.com/w3c/data-shapes/commit/bec7b6852529acc8095 >>>>>>>>>>>>>>> 4dbc38cf4e435861238a2> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://github.com/w3c/data-shapes/commit/bec7b6852529acc8095 >>>>>>>>>>>>>>> 4dbc38cf4e435861238a2 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://github.com/w3c/data-shapes/commit/bec7b6852529acc8095 >>>>>>>>>>>>>>> 4dbc38cf4e435861238a2>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'd appreciate if WG members could double check >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> definition. >>>>>>>>>>>>>>> Meanwhile I have turned the change above into a >>>>>>>>>>>>>>> PROPOSAL for a >>>>>>>>>>>>>>> future meeting: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-209:_ >>>>>>>>>>>>>>> What_is_a_shape >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-209: >>>>>>>>>>>>>>> _What_is_a_shape> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-209: >>>>>>>>>>>>>>> _What_is_a_shape >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-209: >>>>>>>>>>>>>>> _What_is_a_shape>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Holger >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 24/11/2016 9:49, Irene Polikoff wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I believe the question is "How do I know >>>>>>>>>>>>>>> that a >>>>>>>>>>>>>>> node is a >>>>>>>>>>>>>>> shape?". The spec says that it is >>>>>>>>>>>>>>> "typically" a >>>>>>>>>>>>>>> SHACL instance of >>>>>>>>>>>>>>> sh:Shape. This is one way, but not the >>>>>>>>>>>>>>> definitive >>>>>>>>>>>>>>> way (because of >>>>>>>>>>>>>>> "typically") to determine that something is a >>>>>>>>>>>>>>> shape. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> What are other ways? E.g., any subject of a >>>>>>>>>>>>>>> triple >>>>>>>>>>>>>>> with one of >>>>>>>>>>>>>>> the SHACL target or constraint predicates is >>>>>>>>>>>>>>> a shape. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sun, Nov 20, 2016 at 3:58 PM, RDF Data >>>>>>>>>>>>>>> Shapes >>>>>>>>>>>>>>> Working Group >>>>>>>>>>>>>>> Issue Tracker <sysbot+tracker@w3.org >>>>>>>>>>>>>>> <mailto:sysbot%2Btracker@w3.org> >>>>>>>>>>>>>>> <mailto:sysbot+tracker@w3.org >>>>>>>>>>>>>>> <mailto:sysbot%2Btracker@w3.org>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> shapes-ISSUE-209 (What is a shape?): What >>>>>>>>>>>>>>> is a >>>>>>>>>>>>>>> shape [SHACL Spec] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://www.w3.org/2014/data-shapes/track/issues/209 >>>>>>>>>>>>>>> <http://www.w3.org/2014/data-shapes/track/issues/209> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <http://www.w3.org/2014/data-shapes/track/issues/209 >>>>>>>>>>>>>>> <http://www.w3.org/2014/data-shapes/track/issues/209>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Raised by: Karen Coyle >>>>>>>>>>>>>>> On product: SHACL Spec >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Peter's mail: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oct >>>>>>>>>>>>>>> /0029.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oc >>>>>>>>>>>>>>> t/0029.html> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oc >>>>>>>>>>>>>>> t/0029.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oc >>>>>>>>>>>>>>> t/0029.html>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "Just what are shapes? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The terminology section says: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "Shape >>>>>>>>>>>>>>> A shape is a node in a shapes graph >>>>>>>>>>>>>>> that is >>>>>>>>>>>>>>> typically a SHACL >>>>>>>>>>>>>>> instance of >>>>>>>>>>>>>>> sh:Shape. A shape provides a collection of >>>>>>>>>>>>>>> targets, filters, >>>>>>>>>>>>>>> constraints and >>>>>>>>>>>>>>> parameters of constraint components that >>>>>>>>>>>>>>> specify how a data >>>>>>>>>>>>>>> graph is >>>>>>>>>>>>>>> validated against the shape. Shapes can >>>>>>>>>>>>>>> also >>>>>>>>>>>>>>> provide >>>>>>>>>>>>>>> non-validating >>>>>>>>>>>>>>> information, such as labels and comments." >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Section 2 says: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "Shapes define constraints that a set of >>>>>>>>>>>>>>> focus >>>>>>>>>>>>>>> nodes can be >>>>>>>>>>>>>>> validated >>>>>>>>>>>>>>> against." >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This doesn't, however, provide guidance in >>>>>>>>>>>>>>> determining what >>>>>>>>>>>>>>> the shapes in a >>>>>>>>>>>>>>> shapes graph are." >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (more in the email) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Karen Coyle >>>>>>>>>>>>>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> >>>>>>>>>>>>>>> http://kcoyle.net >>>>>>>>>>>>>>> m: 1-510-435-8234 <tel:1-510-435-8234> >>>>>>>>>>>>>>> skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Karen Coyle >>>>>>>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >>>>>>>>> m: 1-510-435-8234 >>>>>>>>> skype: kcoylenet/+1-510-984-3600 >>>>>>> >>>>>>> -- >>>>>>> Karen Coyle >>>>>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >>>>>>> m: 1-510-435-8234 >>>>>>> skype: kcoylenet/+1-510-984-3600 >>>>>> >>>>>> >>>>> >>>> >>> >>> -- >>> Karen Coyle >>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >>> m: 1-510-435-8234 >>> skype: kcoylenet/+1-510-984-3600 >>> >> > > -- > Karen Coyle > kcoyle@kcoyle.net http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet/+1-510-984-3600
Received on Wednesday, 7 December 2016 21:10:08 UTC