Hi Steve,
the UI needs to decide what kind of input widget it presents based on
what it can find out from the ontology. The case of sh:hasValue is
difficult, because it would need to make some assumptions about what
type of value is most likely needed. In your case this is extra
difficult because the property shape doesn't specify sh:datatype or
sh:class, and even worse, uses a property path. Due to lack of other
info it thus "guesses" you may want to use an xsd:string and presents
you with a string input field.
Some things are better edited in source code, and I recommend taking a
look at the source code from time to time. The EDG web UI allows
arranging the source code and form panels side by side, making it easier
to spot such mistakes.
Holger
On 10/14/2020 5:52 AM, Steve Ray wrote:
Irene,
Thanks for the feedback. I was working on a "double-hop" property
shape as part of this exercise, and stumbled on what I would
characterize as a UI bug in TBC. Note in the screenshot that when I
chose "Add Empty Row" when setting a value for sh:hasValue, the
datatype shows up as string.
Autocompletion works as expected (see second screenshot)
But here's the source code view (see third screenshot). I lost a
couple of hours wondering why the validation was failing until Ralph
helpfully pointed out the quotation marks in the source code, which of
course should not be there.
Steve
On Mon, Oct 12, 2020 at 3:02 PM Irene Polikoff <[email protected]> wrote:
I am pretty sure this was a question about the most appropriate SHACL modeling
pattern as opposed to OWL vs SHACL.
Regarding reasoning, TopBraid users typically use SHACL rules for reasoning.
SWRL is pretty obsolete. It will never be a standard and is mainly supported by
Protege.
I was also assuming that PowerMeasurementDevice (if such class is created)
could be a subclass of a MeasurementDevice and instances would be the actual
devices - may be from different manufacturers, etc. Of course, the decision on
where to stop with classes and subclasses and start using instances is also
situational - it depends.
On Oct 12, 2020, at 3:16 PM, Michael DeBellis <[email protected]> wrote:
I'm looking for guidance on best practices for modeling the
following kind of pattern:
A PowerMeasurementDevice takes measurements of Power.
In my opinion, you haven't said enough about your problem to really give a good
answer to the question. You can model this either with OWL or SHACL. Actually,
you will probably use OWL either way just to model that a
PowerMeasurementDevice is an instance of Device which is probably a subclass of
something else and that producesMeasurements is an object property. So the real
question is: is it better to use OWL alone or OWL + SHACL?
The standard answer to these kinds of questions is usually: "use OWL for reasoning
and SHACL for constraints" but of course things like the domain and range of a
property (like most things that can be modeled in SHACL) can be modeled either way, as an
axiom for reasoning or as a constraint on data.
I think what it really comes down to is what kind of data do you have? If you
are creating say an expert system ontology from scratch and are also going to
populate it with rules in SWRL or some other language then probably OWL alone
is better. If you have a lot of existing real world data which may contain
values of producesMeasurements that don't have the appropriate values for their
domain and/or range then you probably want to use SHACL. Also, how volatile is
your data? If there is constantly new data coming in (which may not match the
constraint) then SHACL is probably better. If it is relatively static and your
data will tend to be well formed then OWL axioms are probably better.
As you probably know, the issue with using OWL axioms is the first time you
encounter an Individual that doesn't have the proper domain or range then your
entire ontology is inconsistent which means it can't be used for any reasoning
until the bad data is fixed or removed. With SHACL you just get a report (or
some other user defined action) about the bad data but it doesn't make your
entire model inconsistent.
Michael
michaeldebellis.com
On Mon, Oct 12, 2020 at 11:39 AM Steve Ray <[email protected]> wrote:
This question is directed at anyone in this group who is fluent in
SHACL. I'm looking for guidance on best practices for modeling the
following kind of pattern:
A PowerMeasurementDevice takes measurements of Power.
Is it better practice to put a SHACL constraint on the instances of a
class called PowerMeasurement (that they should be measurements of
Power), where:
PowerMeasurementDevice producesMeasurements PowerMeasurement .
or, should I just define a property shape for PowerMeasurementDevice
such that the property producesMeasurements has the appropriate
constraints? In this case, I don't need to create a special class
called PowerMeasurement.
Any thoughts one way or the other? I'm leaning toward the explicit
definition of a PowerMeasurement class, but it's more intuition than
principle.
Steve
--
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/CAGUep87ZvBUe0urm5V6rxFPJOVpYCzG3Aa0qz7DxFBH-9TR9Wg%40mail.gmail.com.
--
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/CALGFikcT82t%3DeKh6bnEdiL8hkTCoOv89-R5my0WvfKrztTVibg%40mail.gmail.com.
--
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/1D78D8DF-B1ED-4122-B936-81D3046176C5%40topquadrant.com.
--
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/e1cb2bd5-0763-5aa2-a166-8d52164e22da%40topquadrant.com.
