On 21/02/2020 06:20, Michael Puckett wrote:
Thanks Holger. I have downloaded the Java implementation and have been
working successfully with sh:rule/sh:values. I have been using
shaclinfer.bat to do the sorts of transformations I was looking to do.
Is the shaclinfer part, where it provides the inferred graph, a
standard part of any compliant SHACL engine? If not, I think it would
be helpful to add it to the spec.
Are you referring to using the inferences as part of validation? The
SHACL-AF spec defines the sh:Rules Entailment Regime
https://www.w3.org/TR/shacl-af/#Rules
which can be used as value of sh:entailment to instruct compliant
validation engines to also operate on the inferred triples. Like
everything in SHACL-AF, these features are not part of the SHACL
standard recommendation, but have a lesser W3C status of a W3C Note. As
a result, they are not required. A future SHACL W3C WG could move the
SHACL-AF spec forward but if that goes through the W3C process it would
be quite a long shot. The only realistic process is for the SHACL
Community Group to try to "finish" that spec and then submit it to W3C
for a quick turn around. Or, like we do, just assume it's a de-facto
standard and use it in practice. TopBraid products make heavy use of
sh:values now, e.g. the inferred values automatically show up on forms
because they are computed on the fly as part of our GraphQL requests.
Holger
Michael
On Sunday, February 16, 2020 at 6:06:34 PM UTC-5, Holger Knublauch wrote:
Hi Michael,
yes, you are right that the official main goal of SHACL was
validation. This was mainly for political reasons because graph
validation is what the W3C WG was chartered to do. However
TopBraid products and users have used SPIN rules in the past to
define transformations between different classes of RDF data
instances. So we used those use cases as input to the SHACL-AF
spec, which includes the SHACL rules, and became a separate
(optional) deliverable of the SHACL WG. These rules are more
general than SPIN because SHACL's target mechanism is more
flexible than the class-centric design of SPIN. For rule-based
transformations, the shapes and their target declarations would
identify the focus nodes that the rules apply to.
The TopBraid SHACL API does support the execution of rules
including a command line tool. Our SHACL JavaScript implementation
and its Playground was primarily a demonstrator and not meant for
serious work.
On your question, where do you see the link between validation and
inferencing/transformation rules? Validation is technically not a
requirement for rules, except in places like sh:condition in
triple rules.
FWIW we try to use property value rules (sh:values) instead of
triple rules due to the more natural and compact syntax, see
https://w3c.github.io/shacl/shacl-af/#PropertyValueRule
<https://w3c.github.io/shacl/shacl-af/#PropertyValueRule>
Holger
On 15/02/2020 10:17, Michael Puckett wrote:
Hi, I'm new and I have an idea for SHACL that might go beyond its
intended purpose but could potentially be very powerful.
I am interested in the fact that SHACL Rules can modify the data
graph.
It might be possible to use Rules as an XSLT-like transformation
engine for RDF/JSON-LD.
I would like to take data from one graph and process it with
SHACL Rules and retrieve the transformed graph.
I have an example gist here:
https://gist.github.com/michaelcpuckett/35bf9773df25e3639e55ae15299ae63e
<https://gist.github.com/michaelcpuckett/35bf9773df25e3639e55ae15299ae63e>
The JS Playground doesn't look like it supports Rules, because
the above fails validation. (I haven't tried the Java
implementation yet, I'm interested to see if it would validate
there. I might have a syntax error.)
Of course, as I understand it, if it did validate, there would be
no Validation Report.
I would like to suggest that in a future version of SHACL, a
Validation Report, including the inferred data graph, could be
provided with an explicit flag. The inferred data graph would be
the result of transformation.
Perhaps this been considered already, or this is already
possible? I would appreciate any feedback (or ideas for extension
mechanisms if this goes beyond core).
Thanks!
Michael
--
You received this message because you are subscribed to the
Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected] <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/35675d95-f3d2-452c-ada2-093bdf3752bf%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/35675d95-f3d2-452c-ada2-093bdf3752bf%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/c9e04584-d934-4d0e-9a9c-6590ee1a49aa%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/c9e04584-d934-4d0e-9a9c-6590ee1a49aa%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "TopBraid
Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/cc8390cc-1fe1-efdc-d4e7-2758bba9db01%40topquadrant.com.
