On 2021-07-13 12:13 am, Tim Smith wrote:
Thanks Holger and Irene. Perhaps I have been trying to stretch SHACL
in ways it was not intended. I had interpreted sh:name to
represent the name of the path /in the context/ of the property
shape. If it is intended to universally be the name of the path, then
we can just use the label of the property (assuming the path is not a
property path).
Not exactly. The global label would be global across all classes and
shapes, while sh:name is specific to the (surrounding) class.
Furthermore, you don't even need any global property axioms in SHACL,
and that's a good thing. No object-oriented modeling language for
example has a notion of global property/field declarations either.
However, this does present some display issues when using multiple
shapes against the same property. Here is "Holding Company" in EDG
using Holger's more efficient approach as shared above. Now there are
three declared properties (shapes), all shown as "owns". I do think
in the context of the property shape that is being displayed, we
should have the cardinality displayed based on the shape.
image.png
Yes, on a branch for 7.1 I have implemented this (more useful) display:
On a broader note, I know my potential EDG users will never know the
difference between properties and property shapes. e.g. What appears
in the "declared properties" group are shapes. Thus I have been
trying to use shapes as a way to drive the UI, but maybe in a way that
is contrary to the standard. Let me briefly explain.
A very common ontological modeling use case is deciding what property
to use. I, and others, try to limit the number of properties by using
"generic" properties that convey the correct semantics, e.g. the
"owns" property in my example. However, this may be too generic for
the user that is viewing or creating instances, especially when there
are conditions on the set of objects. e.g. must be one Racing and one
Movie company. QVCs enable capturing the correct semantics. In
addition to capturing the semantics, in many cases I want to show the
users what objects adhere to the semantics defined by each QVC, not
simply a list of all things that are an object of "owns".
As I understand it today, the only solution is to create subproperties
of df:owns and create property shapes for each new property. I don't
want to go down this path if at all possible since it will lead to
property explosion where I'm creating a property for every "generic"
property/class combination, e.g. df:ownsRacingCompany,
df:ownsMovieCompany, etc... I did this for a control system ontology
and I ended up with nearly 1000 properties where all I really needed
was edg:input and edg:output because I needed to be able to show the
user the possible set of inputs and outputs and what was connected (or
not) to each of them. To me this was an example of the UI driving the
model.
Anyway... I will explore other ways to achieve my objective. Maybe
some custom UI elements are warranted.
I am aware that other projects (esp in the engineering space) are using
qualified value constraints like you intended to. We will improve tool
support as described above. With that, what other obstacles would remain
for you?
Having said this, "normal" properties will win in most cases. Simpler to
define and faster to query (with "owns" you'd need FILTERs everywhere).
So while you may need to define 1000 properties, you will now need to
define 1000 QVC property shapes. Is this really an improvement?
Holger
Thanks for the always informative discussion,
Tim
On Fri, Jul 9, 2021 at 10:08 PM Irene Polikoff <ir...@topquadrant.com
<mailto:ir...@topquadrant.com>> wrote:
To add to what Holger said, this is the reason sh:name exists. If
this was the label of the property shape, then there would be no
need to define a new property. One could simply use rdfs:label -
as Holger’s example shows.
Sh:name was created because it is not the label of the resource
that is the subject of the sh:name triples. Instead, it is a
display label for the path.
On Jul 8, 2021, at 9:34 PM, Holger Knublauch
<hol...@topquadrant.com <mailto:hol...@topquadrant.com>> wrote:
I don't agree on that and believe your use of sh:name does not
align with how the standard intended it to be used. sh:name is
supposed to be the display label for the property, e.g. "owns"
and not the label of the property shape. The label of the
property shape should be in rdfs:label, like you would do it for
node shapes.
--
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 topbraid-users+unsubscr...@googlegroups.com
<mailto:topbraid-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/47B2E936-0AA8-46BF-82E0-E0DF31F20156%40topquadrant.com
<https://groups.google.com/d/msgid/topbraid-users/47B2E936-0AA8-46BF-82E0-E0DF31F20156%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 topbraid-users+unsubscr...@googlegroups.com
<mailto:topbraid-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/CAF0WbnJJ2oK7UKe8sW7L_Whkt9WP7MsJjdg2xNoVtq7yPpt3Hw%40mail.gmail.com
<https://groups.google.com/d/msgid/topbraid-users/CAF0WbnJJ2oK7UKe8sW7L_Whkt9WP7MsJjdg2xNoVtq7yPpt3Hw%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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/9186b1a7-602c-b1b6-fcc8-6141fa0dd054%40topquadrant.com.
