- From: Irene Polikoff <irene@topquadrant.com>
- Date: Thu, 1 Dec 2016 13:20:16 -0500
- To: kcoyle@kcoyle.net
- Cc: public-data-shapes-wg@w3.org
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> 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>> 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-node >>>>>>> >>>>>>> <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-shapes-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-node >>>>>>> >>>>>>> <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-shapes-graph >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <https://mail.google.com/mail/u/0/#m_1017120090268237992_dfn-shapes-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>>> 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/bec7b6852529acc80954dbc38cf4e435861238a2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954dbc38cf4e435861238a2> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954dbc38cf4e435861238a2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <https://github.com/w3c/data-shapes/commit/bec7b6852529acc80954dbc38cf4e435861238a2>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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/2016Oct/0029.html> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oct/0029.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Oct/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 http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet/+1-510-984-3600 >
Received on Thursday, 1 December 2016 18:20:54 UTC