Print

Print


Hi Karen, et al.,

It looks to me like the version on the W3C's github has been updated recently as well [1], though there are still minor differences between the two. The latest W3C one might be the slightly more up-to-date version at this time. It may be worth asking which, if any, should be considered canonical.

It's also worth noting that I found the TopQuadrant version via Holger's post to the W3C list, [2] which identifies this code as a prototype with many open ends and that is update to change. Still, I find the example constraints file helpful and illustrative. [3]

-Corey

[1]https://github.com/w3c/data-shapes/blob/gh-pages/shacl/shacl.shacl.ttl
[2]https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jul/0055.html
[3]https://github.com/TopQuadrant/shacl/blob/master/src/test/resources/shaclsquare.shacl.ttl

On Thu, Jul 30, 2015 at 1:50 PM, Karen Coyle <[log in to unmask]> wrote:
Note: I was looking at the SHACL ttl file from the W3C web site, which turns out to be quite incomplete. Corey found this file:

https://raw.githubusercontent.com/TopQuadrant/shacl/master/src/main/resources/etc/shacl.shacl.ttl

which makes much more sense. So some of the problems I ran into may be resolved by this file. I'll see if I can determine that.

kc



On 7/29/15 12:38 PM, Karen Coyle wrote:

I strongly suggest adding documentation and owl DatatypeProperty
declarations with ranges as xsd datatypes. Also to include
ObjectProperty declarations with rdfs:Resource as range. I dont think
adding just those would contradict with anything, and it would help
using SHACL schema with some existing RDF editors.

Even with such patches, tools that are not aware of SHACL could still
not be used for data entry of SHACL instance models. They don't
understand sh:property etc.

If SHACL is an RDF vocabulary, then tools should only need to understand
RDF semantics. If SHACL cannot be understood as an RDF vocabulary, then
I think we have a problem. At this point, it's probably best to take
this to the W3C group discussion, since this is a concern for that
group. I'll try to formulate something for that mailing list.

kc

Tools that do not include full SHACL support
may use an extended version of the SHACL Turtle file, as you indicate. A
simple way of producing range triples is a SPARQL query:

CONSTRUCT {
      ?predicate rdfs:range ?range .
}
WHERE {
      ?shape sh:property ?pc .
      ?pc sh:predicate ?predicate .
      ?pc sh:valueClass|sh:datatype ?range .
}

For the (hopefully short) transition period until other tools have
caught up, such things may help, and the WG may even produce such an
alternative version as a separate deliverable. But IMHO these
definitions do not belong into the official main document which neither
relies on OWL nor RDFS. Using rdfs:range has consequences (inferences).
And who can predict the fate of OWL from here?

Regards,
Holger



br,
Miika

----- Original Message -----
From: "kcoyle" <[log in to unmask]>
To: [log in to unmask]
Sent: Tuesday, 28 July, 2015 07:14:33
Subject: Re: [RDF AP] Darwin Core, SHACL, and APs

Holger, I'm thinking about folks who will use available tools to create
the SHACL definitions for their data. I only have this one experience,
so I'm curious what others find. That said, there aren't a lot of open
source/open access tools for RDF data creation, and I presume that most
are imperfect. But if any standard is going to proliferate, it has to
fit into the tools and workflow that are available to people. Having to
have new tools created will undoubtedly slow down acceptance.

I hope more people will try out SHACL within their current RDF
environments and report back.

kc

On 7/27/15 3:24 PM, Holger Knublauch wrote:
Hi Karen,

On 7/28/15 3:29 AM, Karen Coyle wrote:
Miika, the properties are there, but none have ranges, which I think
is unfortunate. I presume that ranges would be appropriate, and a
stated range serves in a sense as documentation for the intended use
of the property.
The intended use of the SHACL properties is already encoded in the
Turtle file, using SHACL itself. Adding rdfs:domains and ranges
would be
incorrect and misleading. It would cause undesired side effects such as
inferencing and suffers from the very problems that SHACL was supposed
to fix - domains and ranges are open-world concepts. Furthermore, the
usage of properties is context-specific, i.e. properties can have
different valueClass depending on the context class.

Having said this, if someone wants to go back to OWL/RDFS, it could be
possible to create a separate OWL vocabulary for SHACL that uses
owl:Restrictions instead of sh:PropertyConstraints to cover parts of
SHACL. This may help bridge the gap to tools that are not (yet?) SHACL
aware. But since SHACL does not depend on OWL at all, and OWL has
open-world interpretation, it makes no sense to add such things to the
main SHACL document.

The reason Protege fails to load them is that it converts all RDF to
OWL (via the Manchester OWL convert API, I believe), and the algorithm
drops them due to lack of information that would indicate what the OWL
equivalent is. (Note that the Dublin Core 1.1 ontology suffers the
same fate for the same reason.) Although they are valid RDF, the
properties are, IMO, under-defined for practical use.
The Protege developers picked the OWL API as its foundation. The OWL
API
is not a good choice to operate on arbitrary RDF. Expecting Protege to
work with SHACL out of the box is a bit like expecting a UML editor to
work with XML Schema - both UML and XML Schema ultimately use XML yet
are very different languages. In addition to the syntactic problems,
tools like Protege would require additional tabs or widgets to edit
SHACL property declarations, shapes, run constraint checks etc. Until
this happens you are better off with either editing SHACL files by hand
or look at SHACL-specific alternatives.

I hope this makes sense. You may want to raise this topic in the Shapes
WG if you are still concerned.

Holger


kc

On 7/27/15 12:03 AM, Miika Alonen wrote:
Hi,

I used SHACL in my example profile. Properties and classes are
defined there at the end of the SHACL schema. Some of the property
declarations might be missing and different from the current draft. I
asked about this from Holger (editor) and he added some of the
missing properties, but also replied that it is not meant to be
traditional RDF(s) vocabulary (and those property declarations are
not really needed) as SHACL has its own way of declaring properties.

So, i suppose Protege (or any other editor) would need new module to
fully support SHACL once it is finished.

br,
Miika

----- Original Message -----
From: "kcoyle" <[log in to unmask]>
To: [log in to unmask]
Sent: Sunday, 26 July, 2015 23:44:55
Subject: Re: [RDF AP] Darwin Core, SHACL, and APs

Kai, Thomas,

is there an RDF vocabulary behind that that can be shared? I'm
curious
how close it adheres to DSP/DCAM.

Also, has anyone yet played with the SHACL turtle file?[1] It's
probably
just a draft, but I find it to be rather odd, with no ranges on
properties, and classes which are essentially "methods." I'm
curious how
it plays in software people are using. (It fails in Protege[1],
but that
requires a conversion to OWL.)

kc
[1] http://w3c.github.io/data-shapes/shacl/shacl.shacl.ttl
[2] http://protege.stanford.edu/

On 7/23/15 4:08 PM, Kai Eckert wrote:
BTW, Thomas has provided the long-missed implementation of DSP,
so the
point of your interviewees is not valid anymore, at least for RDF
data.



--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600



--
Corey A Harper
Metadata Services Librarian
New York University Libraries
20 Cooper Square, 3rd Floor
New York, NY 10003-7112
212.998.2479
[log in to unmask]