On 11/05/2018 22:19, Steven Michael Folsom wrote:
I realize the examples are not normative, but could the example given
at https://www.w3.org/TR/shacl/#AndConstraintComponent be stated
without the blank nodes? E.g.
ex:SuperShape
a sh:NodeShape ;
sh:property ex:SuperShapePropertyShape .
ex:SuperShapePropertyShape sh:path ex:property ;
sh:minCount 1 .
Yes this is equivalent. We often use URIs for property shapes too. In
that case I would strongly recommend adding the rdf:type
sh:PropertyShape triple too, so that viewers can still understand this
resource outside of the SuperShape context.
ex:ExampleAndShape
a sh:NodeShape ;
/sh:targetNode ex:ValidInstance, ex:InvalidInstance ;/
sh:and (
ex:SuperShape
ex:SubShapePropertyShape
) .
:SubShapePropertyShape sh:path ex:property ;
sh:maxCount 1 .
BTW sh:and is a bit redundant and arguably shouldn't even be in SHACL.
You can simply write
ex:ExampleAndShape
a sh:NodeShape ;
/sh:targetNode ex:ValidInstance, ex:InvalidInstance ;/
sh:node ex:SuperShape ;
sh:node ex:SubShapePropertyShape .
for the same semantics.
Also confirming what I think is true, can property shapes use sh:and
to a similar effect? E.g.
:SubShapePropertyShape sh:path ex:property ;
sh:maxCount 1 ;
sh:and (ex:SubShapePropertyShape) .
Yes property shapes can use sh:and too. Again, sh:node is probably be a
better syntax, esp if you only have one member in the sh:and list.
sh:or is a very different story, as is sh:not.
HTH
Holger
Thanks,
Steven
*From: *<[email protected]> on behalf of Holger
Knublauch <[email protected]>
*Reply-To: *"[email protected]"
<[email protected]>
*Date: *Saturday, April 14, 2018 at 7:16 PM
*To: *"[email protected]" <[email protected]>
*Subject: *Re: [topbraid-users] Compiling Validation and UI/Form
semanatics
On 14/04/2018 3:59, Irene Polikoff wrote:
Overrides are not supported, but inheritance is supported.
For example, you could define minCount but not define maxCount,
then add a definition of maxCount in the “sub shape”.
There are 2 ways of addressing this:
* Classes can also be shapes. If you model that way, all you
need to do is to create a class of all things that your
general property constraints will apply to, then create
subclasses and add additional constraints to them.
o For example, you would create a class Person with property
shapes that say that a person must have name and age. Then
you define a subclass Student with property shapes that
say that students age must be greater than 15 and they
need to have student ID.
* Otherwise, shapes can contain other shapes. You would define a
general shape with constraints you want to use in other
shapes. When you define more specific shapes, you would
include the general shape into them using sh:and.
o https://www.w3.org/TR/shacl/#AndConstraintComponent
An alternative to using sh:and is simply sh:node. In shapes, sh:node
fulfills a similar role as rdfs:subClassOf for classes. For example
state ex:SubShape sh:node ex:SuperShape to ensure that all constraints
defined for SuperShape also apply to the target nodes of SubShape.
(Whether tools will understand this form of inheritance is another
question - currently not all places of the TopBraid forms would use
sh:node although I'd like to move there).
Holger
On Apr 13, 2018, at 1:20 PM, Rebecca Younes
<[email protected] <mailto:[email protected]>>
wrote:
A related question: is it possible for one shape to invoke,
inherit, and/or override values from another shape? For
example, I would like to create a general property shape for a
title property that defines cardinality, sh:class, sh:path,
etc. Then in the context of different form shapes, I would
like to define specific names, descriptions, orders, etc.:
"Album title," "Book title," and so on. Perhaps I would like
to define a default name "Title," which could be overridden by
the specific form shapes. Is any of this possible?
Thanks.
Rebecca Younes
Semantic Application Developer and Ontology Engineer
Cornell University Library Information Technology
On Thursday, April 12, 2018 at 4:17:52 PM UTC-4, Steven Folsom
wrote:
I would be interested to be able to look at any
implementations where /Validation/ shapes are compiled
with non-Validation shapes to build Forms, where that the
validation axioms are maintained in separate shapes from
non-validation (UI) shapes?
Is anyone doing this? We’ve been considering it for easier
maintenance of our various shapes, but right now it’s
easier to see all the axioms needed for the app in one place…
Thanks,
Steven
--
Steven Folsom
Metadata Specialist
Cornell University Library
pronouns: he/him/they/them
http://orcid.org/0000-0003-3427-5769
http://vivo.cornell.edu/individual/sf433
@sf433
--
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]>.
For more options, visit https://groups.google.com/d/optout.
--
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]>.
For more options, visit https://groups.google.com/d/optout.
--
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]>.
For more options, visit https://groups.google.com/d/optout.
--
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]>.
For more options, visit https://groups.google.com/d/optout.
--
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].
For more options, visit https://groups.google.com/d/optout.
