> On Jan 8, 2020, at 2:34 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users
> <[email protected]> wrote:
>
> Tx Irene
>
> In our cen topmodel we have such constructs like:
>
> bs:hasInterior
> a owl:ObjectProperty ;
> rdfs:domain [
> a owl:Class ;
> owl:unionOf (
> bs:PhysicalObject
> bs:Activity
> ) ;
> ] ;
> rdfs:range bs:SpatialRegion ;
> owl:inverseOf bs:hasInterior ;
> skos:prefLabel "has interior"@en ;
> skos:prefLabel "heeft inwendige"@nl ;
> .
>
> Indeed not possible to reason/infer but from just a modelling/representation
> viewpoint we indicate that this property is a property of some
> physicalobject or some activity.
> If there is a hasInterior property in the data but no physicalobject and no
> activity having this property (no object in the triple of type physicalobject
> or activity) there would be a consistency issue right? Or not?
No, there would be no consistency issue unless you have some other information
in the model.
Semantics of this statement is:
If there is a triple
:R1 bs:hasInterior :R2
Then
:R2 a bs:SpatialRegion
And
Either :R1 a bs:PhysicalObject or :R1 a bs:Activity
If you do not have
:R2 a bs:SpatialRegion statement, it can be inferred
If there is no pre-existing statement about the type of :R2, then there is no
issue
If you have
:R2 a example:Thing1
It is not an inconsistency in itself because :R2 can be a member of multiple
classes.
To create an inconsistency, you would need to do something else that would
indicate that :R2 can not be a member of these two classes. The simples thing
is to add {example:Thing1 owl:disjointWIth bs:SpatialRegion} triple. You would
need to add this for every class where such double membership may be an issue.
It is a big modeling overhead. Having said this, this inconsistency could be
picked up by any reasoning approach since the inference is straight forward.
You could have rule-based inferencing, for example. DL reasoner is not
required. Not so with the subject side of the triple.
I am making this point because practically speaking DL reasoning is dead.
Nothing is happening in this field, no commercialization and the academic work
has dwindled down considerably as well. Of course, Protege has a DL reasoner
and if this is your target environment for model validation and interpretation,
then this is not an issue.
With the domain statement, identifying inconsistency becomes harder.
Again, if there is no type statement for :R1, it is not an issue.
If there is a type statement even if you have the appropriate disjoints in
place, I think you would still need a DL reasoner to pick up the inconsistency
since no direct inference could be made about class membership. The reasoner
would have to make all sort of other conclusions - actually create the union
class using a blank node and make :R1 its member and so on. This type of thing
would not, for example, be supported in OWL RL.
There could be some other logical inconsistency besides disjoints that could be
picked up by the DL reasoner. Once you bring OWL into the picture, there are
all sorts of possibilities based on the various restrictions and other axioms
you may have defined for these classes.
But then, if you are using OWL and you added DL reasoner to you applications,
you need to think if and why you want to use domain and range statements to
begin with. There could be all sorts of interplay between these statements and
various OWL expressions that are hard to track down. In my experience, a better
practice is then to stick with restrictions.
Further, declaring inverses adds to potential complexity in terms of possible
inconsistencies and data overhead. We typically recommend that customers avoid
inverses - triples could be navigated in either direction. With SHACL, you
could add constraints on the inverse path as well, without needing the
materialized inverse triple.
>
> Would that be ok or should I better delete those domains at all?
>
> Thx Michel
>
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
> T +31888663107
> M +31630381220
> E [email protected] <mailto:[email protected]>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
> <image001.gif> <http://www.tno.nl/>
> This message may contain information that is not intended for you. If you are
> not the addressee or if this message was sent to you by mistake, you are
> requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use it
> and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
> Van: [email protected] <mailto:[email protected]>
> <[email protected] <mailto:[email protected]>>
> Namens Irene Polikoff
> Verzonden: Tuesday, January 7, 2020 5:11 PM
> Aan: [email protected] <mailto:[email protected]>
> Onderwerp: Re: [topbraid-users] or-domains
>
> Since RDFS is about inferring the domain and range from the available data
> rather than restricting what can be in the data, using OR for domains and
> ranges does not make sense if one is staying with RDFS only. There isn’t
> anything that could be inferred from such statements.
>
> If one is using domains and ranges in combination with OWL, then, depending
> on the OWL axioms, having OR in the domains and ranges could help detect some
> potential inconsistencies.
>
> So, yes to Richard’s suggestion of creating a common superclass. Then you
> could at least infer that subject or object is a member of the super class.
>
> And yes to using using SHACL instead. In such case, I would discourage from
> using rdfs:domain and range unless the goal is to create inferences based on
> this info.
>
> The patterns for SHACL are as follows:
>
> If you want to use a property for members of different classes:
>
> You can define a property shape for a super class
> You can also define a property shape for each individual class/node shape
>
> If you want to say that values of a property could be different datatypes
> e.g., a date or date time, you can use sh:or. For convenience, there are some
> pre-built unions in http://datashapes.org/dash <http://datashapes.org/dash>
>
> If you want to say that values of a property could be members of different
> classes:
>
> You can use a parent class in the sh:class constraint
> You can also use sh:or with multiple sh:class constraints
>
>
>
> On Jan 7, 2020, at 10:32 AM, Steven Michael Folsom <[email protected]
> <mailto:[email protected]>> wrote:
>
> Is this a case where a SHACL NodeShape/s with a targetClass/es and
> PropertyShapes would be helpful?
>
> In some ontology development we’ve done, we decided to leave domains and
> ranges open (to encourage reuse), but also defined some implementation shapes.
>
> From: <[email protected]
> <mailto:[email protected]>> on behalf of Richard Cyganiak
> <[email protected] <mailto:[email protected]>>
> Reply-To: "[email protected]
> <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>
> Date: Tuesday, January 7, 2020 at 9:05 AM
> To: topbraid-users list <[email protected]
> <mailto:[email protected]>>
> Subject: Re: [topbraid-users] or-domains
>
> The closest you can get to that in RDFS is to add a new class that has the
> desired domains as its subclasses, and use that new class as the domain.
>
> Richard
>
>
>
>
> On 7 Jan 2020, at 09:01, 'Bohms, H.M. (Michel)' via TopBraid Suite Users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
>
> Dear,
> How can we have multiple domains in OR-logic in RDFS (ie not having OWL
> unions).
> And also not using particular constructs like schema.org
> <http://schema.org/>’s domainIncludes.
>
> Is there any way other than not having the domains at all?
>
> Thx Michel
>
>
>
>
> Dr. ir. H.M. (Michel) Böhms
> Senior Data Scientist
>
>
>
> T +31888663107
> M +31630381220
> E [email protected] <mailto:[email protected]>
> Location
> <https://www.google.com/maps/place/TNO+-+Locatie+Delft+-+Stieltjesweg/@52.000788,4.3745183,17z/data=!3m1!4b1!4m5!3m4!1s0x47c5b58c52869997:0x56681566be3b8c88!8m2!3d52.000788!4d4.376707>
>
>
> <image001.gif> <http://www.tno.nl/>
> This message may contain information that is not intended for you. If you are
> not the addressee or if this message was sent to you by mistake, you are
> requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use it
> and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
>
>
> --
> 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/c1a3101dbb0442a0bf31fc8f08bfb692%40tno.nl
>
> <https://groups.google.com/d/msgid/topbraid-users/c1a3101dbb0442a0bf31fc8f08bfb692%40tno.nl?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/204378D0-C0AA-4EF6-B41A-D72D816726A5%40topquadrant.com
>
> <https://groups.google.com/d/msgid/topbraid-users/204378D0-C0AA-4EF6-B41A-D72D816726A5%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/FB8617FD-6C8D-4387-B049-D694A0443586%40cornell.edu
>
> <https://groups.google.com/d/msgid/topbraid-users/FB8617FD-6C8D-4387-B049-D694A0443586%40cornell.edu?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/E8961EBD-5D52-47E2-9F15-0CD349F69CE8%40topquadrant.com
>
> <https://groups.google.com/d/msgid/topbraid-users/E8961EBD-5D52-47E2-9F15-0CD349F69CE8%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/c03d58686bc7441caab867774773e051%40tno.nl
>
> <https://groups.google.com/d/msgid/topbraid-users/c03d58686bc7441caab867774773e051%40tno.nl?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/3BC7F9B5-8C19-45D7-A1B8-E86971FAF9F2%40topquadrant.com.
