Irene,
To answer your question about what my second case would look like,
here's a working example:
test1:PressureMeasuringDevice
a owl:Class ;
a sh:NodeShape ;
rdfs:subClassOf owl:Thing ;
sh:property [
a sh:PropertyShape ;
sh:path test1:producesMeasurements ;
sh:class qudt:Quantity ;
sh:name "produces measurements" ;
] ;
sh:property [
a sh:PropertyShape ;
sh:path (
test1:producesMeasurements
qudt:unit
qudt:hasQuantityKind
) ;
sh:hasValue <http://qudt.org/vocab/quantitykind/ForcePerArea> ;
sh:name "produces measurements" ;
] ;
.
Note that this does not require the definition of a constrained class
PowerMeasurement. Instead, it just says "I expect an instance of the
generalized qudt:Quantity class, but it had better have a unit with a
quantitykind of ForcePerArea".
So, the advantage of this method is there are fewer subClasses of my
Measurement class that I would have to define. The cost is more
complex property shapes.
I'm quite interested in your opinion of this.
Steve
On Mon, Oct 12, 2020 at 12:04 PM Irene Polikoff <ir...@topquadrant.com> wrote:
>
> I do not understand the difference between two options you are outlining. In
> the second case, how would the constraint look like?
>
> The bigger question that would ultimately determine the answer is “what you
> would like to accomplish by producing this model and what do you expect to
> see in typical data that you will use with it?”. In other words, what do you
> want it to do e.g., what constraint violations would you like it to produce
> when validating what kind of data, what inferences would you like it to
> create if any?
>
> There are few general best practices that can be stated in abstract, such as:
>
> Do not use inverse properties; instead, use shapes with inverse paths
> When deciding what direction to create a property in, go from “many” to “one”
>
>
> But for most guidance, the data and goals need to be understood. There are
> many different options and alternatives with SHACL. Even with the ones above
> it is not “100% must do", ultimately, it all depends.
>
> On Oct 12, 2020, at 2:38 PM, Steve Ray <st...@steveray.com> 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 topbraid-users+unsubscr...@googlegroups.com.
> 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 topbraid-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/topbraid-users/E7D12854-E0D7-4342-AB1C-989E1CD1D12A%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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/CAGUep85%2B0qGh7WHakFjq2Y0hRfnWKMOBMUG91MaYOuOCJFTB6A%40mail.gmail.com.
