Just to add a tiny bit of info in case it's not clear:
If you have multiple property shapes on the same property (anywhere in
the superclass hierarchy) the semantics of them will be merged together.
It doesn't matter if the PropertyShape instance is different - the
constraints are simply all treated the same. This also means all
sh:class constraints would be checked together and the instances need to
fulfill them all. This usually only works if there is a subclass
relationship between those.
Holger
On 8/07/2020 13:47, Irene Polikoff wrote:
Hi Tim,
It would be highly irregular to create, for the same class/node shape,
multiple property shapes with the same path and give them different
sh:name. It would be misleading as, in the data, these will be the
same properties.
Further, what you are defining below is contradictory
pgont:FVNR
a edg:CustomAssetClass ;
a sh:NodeShape ;
edg:acronym "FVNR" ;
edg:description "To Be Determined" ;
rdfs:isDefinedBy <http://data.pg.com/data/graph/Controls> ;
rdfs:label "FVNR" ;
rdfs:subClassOf pgont:ElectricMotorStarter ;
sh:property pgont:FVNR_Sts_Overload-output ;
sh:property pgont:FVNR_Sts_Running-output ;
.
pgont:FVNR_Sts_Overload-output
a sh:PropertyShape ;
sh:path edg:output ;
rdfs:isDefinedBy <http://data.pg.com/data/graph/Controls> ;
sh:class pgont:FaultCondition ;
sh:description "FF: Control Overload" ;
sh:group edg:TraceableGroup ;
sh:maxCount 1 ;
sh:name "Sts_Overload" ;
sh:order "25"^^xsd:decimal ;
.
pgont:FVNR_Sts_Running-output
a sh:PropertyShape ;
sh:path edg:output ;
rdfs:isDefinedBy <http://data.pg.com/data/graph/Controls> ;
sh:class pgont:RunningStatus ;
sh:description "FF: Running Status" ;
sh:group edg:TraceableGroup ;
sh:maxCount 1 ;
sh:name "Sts_Running" ;
sh:order "25"^^xsd:decimal ;
The first property shape says that an instance of pgont:FVNR can have
at most one value for edg:output and the value must be a member of
pgont:FaultCondition class.
The second property shape says that an instance of pgont:FVNR can have
at most one value for edg:output and the value must be a member of
pgont:RunningStatus class.
The only way this could be true is if:either pgont:RunningStatus is a
subclass of pgont:FaultCondition or pgont:FaultCondition is a subclass
of pgont:RunningStatus AND, of course, these shapes say that you would
not have more than one triple with a given subject and edg:output as a
predicate.
Qualified value shapes will solve this problem, but on the form it is
the same path and there is no way to separate these triples.
Ultimately, you would have in the data:
:R1 edg:output :R2, :R3 and so on.
And the UI will display them together. The edit form is not going to
be able to figure out that {:R1 edg:output :R2} corresponds to the
property shape 1 while {:R1 edg:output :R3} corresponds to the
property shape 2 and therefore it should, somehow, display them
separately and let you enter and modify them separately.
This addressed the common OWL use case where the same property
pointed to instances of different classes
Yes, you can do this with SHACL by either having all these classes be
a subclass of a common parent or by using qualified value shapes.
and it was pertinent to the user to show them the class of the
instance to tell them what they were seeing.
This does not change the nature of the property in the data, so the
field name itself is the same. The values would have different types.
If this is for display only (basically a report) and not for editing,
you could generate a view that would display whatever you want e.g.,
display the class they belong to in parenthesis after each resource.
You could, for example, create another property e.g., :typedOutput and
back it by sh:values rule that would generate its values by taking
labels of the resources that are values of edg:output and appending
the class label to them.
On Jul 7, 2020, at 9:14 PM, Tim Smith <[email protected]
<mailto:[email protected]>> wrote:
Hi Holger,
Thank you for the tip on QualifiedValueShapeConstraintComponent. I'm
not deep enough into SHACL to reliably make the best choice. Time is
the best teacher!
Regarding sh:name... I was specifically trying to avoid "property
proliferation" as I already have "class proliferation" when capturing
the different types of outputs for the 128 device types in my model.
One of my perceived benefits of SHACL was to be able to
reuse properties but give each use a different semantic meaning by
naming the property shape accordingly. This addressed the common OWL
use case where the same property pointed to instances of different
classes and it was pertinent to the user to show them the class of
the instance to tell them what they were seeing.
Prior to today, I thought the forms just pulled the name from sh:name
but I see now that it does something like pulling the first sh:name
it encounters for a specific sh:path and re-uses it. I noticed this
artifact when looking at more complicated device types that have
numerous outputs like a Flow Controller. FVNR is a simple case. Is
there a reason that the form doesn't just display the sh:name to the
user, regardless of the property? I'm trying to determine if the
user interface is about to drive the modeling or if there is some
underlying aspect of SHACL that I'm missing. If it's the former, is
there a possibility to re-visit the implementation? I have 128
classes that have this problem. (note that it won't take 128
properties to fix it but it is a common modeling pattern in my domains)
Thanks,
Tim
On Tue, Jul 7, 2020 at 8:43 PM Holger Knublauch
<[email protected] <mailto:[email protected]>> wrote:
Hi Tim,
if you want to use the same property I think you're rather
looking at
https://www.w3.org/TR/shacl/#QualifiedValueShapeConstraintComponent
to say that "one of them needs to be running indicator" and "one
of them needs to be fault indicator".
But while that would work on a constraint checking level, it will
not make sense w.r.t. sh:name and the form editor. The label
should be the same in both cases, which I believe indicates that
you're better off introducing separate properties.
Holger
On 8/07/2020 10:02, Tim Smith wrote:
Hi Holger,
In this case, that is correct. The FVNR class represents a
physical device, a type of electric motor starter. These
devices have two outputs, a running indicator and a fault
indicator. These outputs are typically wired into a
Programmable Logic Controller (PLC). Thus, I've chosen to model
the outputs as specific types of data elements. This model is
intended to be able capture and show lineage for all of the data
elements produced by devices on a manufacturing line. This data
typically flows into a PLC and out into various OT/IT systems.
It will also enable me to capture the control loops on the line.
I own the model and am open to better ways of doing it.
Tim
On Tue, Jul 7, 2020 at 7:13 PM Holger Knublauch
<[email protected] <mailto:[email protected]>> wrote:
Hi Tim,
are you sure both property shapes are about the same
property edg:output? This doesn't look right because they
carry different sh:class constraints in both cases.
Regards,
Holger
On 8/07/2020 04:52, Tim Smith wrote:
Hi,
I am auto-generating classes and property shapes from
spreadsheets. I have an issue where EDG is not displaying
the name of the property shape correctly in the declared
properties section of a class form. In the example below,
note that Sts_Overload is displayed as the property name in
both cases but sh:name contains Sts_Running for the upper
entry. Source code for the class/node shape and property
shapes is pasted at the bottom. This is happening for all
of my generated classes but does not happen for classes and
property shapes I manually create in EDG.
Note that when I say generated, I use an insert query in
TBC to construct the triples from a spreadsheet and insert
them into an empty graph. The graph containing the triples
is then imported into an empty ontology in EDG.
I'm baffled as to what is different and I'm hoping another
set of eyes will see the problem. Thanks in advance for
your help,
Tim
<image.png>
pgont:FVNR
a edg:CustomAssetClass ;
a sh:NodeShape ;
edg:acronym "FVNR" ;
edg:description "To Be Determined" ;
rdfs:isDefinedBy <http://data.pg.com/data/graph/Controls> ;
rdfs:label "FVNR" ;
rdfs:subClassOf pgont:ElectricMotorStarter ;
sh:property pgont:FVNR_Sts_Overload-output ;
sh:property pgont:FVNR_Sts_Running-output ;
.
pgont:FVNR_Sts_Overload-output
a sh:PropertyShape ;
sh:path edg:output ;
rdfs:isDefinedBy <http://data.pg.com/data/graph/Controls> ;
sh:class pgont:FaultCondition ;
sh:description "FF: Control Overload" ;
sh:group edg:TraceableGroup ;
sh:maxCount 1 ;
sh:name "Sts_Overload" ;
sh:order "25"^^xsd:decimal ;
.
pgont:FVNR_Sts_Running-output
a sh:PropertyShape ;
sh:path edg:output ;
rdfs:isDefinedBy <http://data.pg.com/data/graph/Controls> ;
sh:class pgont:RunningStatus ;
sh:description "FF: Running Status" ;
sh:group edg:TraceableGroup ;
sh:maxCount 1 ;
sh:name "Sts_Running" ;
sh:order "25"^^xsd:decimal ;
.
--
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/CAF0WbnLc5O0h1Q29OB5ZAqPfmYkT0KbrfVkyJmy7z8-iZdqBsA%40mail.gmail.com
<https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLc5O0h1Q29OB5ZAqPfmYkT0KbrfVkyJmy7z8-iZdqBsA%40mail.gmail.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/f9493d61-59fe-b295-373c-899efeffb5e6%40topquadrant.com
<https://groups.google.com/d/msgid/topbraid-users/f9493d61-59fe-b295-373c-899efeffb5e6%40topquadrant.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/CAF0Wbn%2BYFYEp-1aMyt6tKB_ajJHBCbjNA2MRZ-xsdXV_FwcRsw%40mail.gmail.com
<https://groups.google.com/d/msgid/topbraid-users/CAF0Wbn%2BYFYEp-1aMyt6tKB_ajJHBCbjNA2MRZ-xsdXV_FwcRsw%40mail.gmail.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/87b2543a-36c1-0dca-6901-30b5faa0b7b3%40topquadrant.com
<https://groups.google.com/d/msgid/topbraid-users/87b2543a-36c1-0dca-6901-30b5faa0b7b3%40topquadrant.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/CAF0WbnLigyhpXZEnwUhdccdjURmYKF%2BbrnSb84ReJW1RLEcC%2BA%40mail.gmail.com
<https://groups.google.com/d/msgid/topbraid-users/CAF0WbnLigyhpXZEnwUhdccdjURmYKF%2BbrnSb84ReJW1RLEcC%2BA%40mail.gmail.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/35C166CF-900B-4FFB-9766-C911F10EFB2A%40topquadrant.com
<https://groups.google.com/d/msgid/topbraid-users/35C166CF-900B-4FFB-9766-C911F10EFB2A%40topquadrant.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/20eb8f08-cdb4-7617-e9c2-fe80f872949e%40topquadrant.com.
