W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > November 2016

Re: shapes-ISSUE-209 (What is a shape?): What is a shape [SHACL Spec]

From: Irene Polikoff <irene@topquadrant.com>
Date: Mon, 28 Nov 2016 12:42:53 -0500
Message-Id: <F61A6073-13F1-4875-974D-9B193017C6A2@topquadrant.com>
Cc: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
+1

I also notice that questions exchanged in the working emails are often phrased like "Is ex:Resource a shape?" or "What are the targets of ex:Resource shape?". This seems to imply a general consensus that shape itself is a node. If shape was defined as a graph, questions could no longer be phrased this way.

Sent from my iPhone

> On Nov 28, 2016, at 5:43 AM, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote:
> 
> Hi Karen, 
> 
> I find the graph-based definition not so fitting for SHACL. 
> When we say that a shape is an RDF node, then we also imply that a shape is part of a graph (the RDF graph that contains that node).
> The node has arcs from / to the node and this is how we define targets, constraints etc already
> 
> The graph-based definition would also create a confusion wrt the shapes graph.
> 
>> On Mon, Nov 28, 2016 at 2:28 AM, Holger Knublauch <holger@topquadrant.com> 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).
>> 
>> 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>
> 
> 
> 
> -- 
> 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 Monday, 28 November 2016 17:43:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 28 November 2016 17:43:43 UTC