Hi Irene Thx for your extensive and clear reply. I realise now that where I said earlier Domain indicates that object is of type x or y I should have said Domain indicates that object is at least of type x or y...but indeed can be also of any other type too...making consistency issues more complex anyway at least harder at subject side as you explained...
For me it means in the end I better delete the domains and inverses. The latter since they do not convey any inverse restrictions. Thx michel Op 8 jan. 2020 18:59 schreef Irene Polikoff <[email protected]>: On Jan 8, 2020, at 2:34 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <[email protected]<mailto:[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 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]<mailto:[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<https://groups.google.com/d/msgid/topbraid-users/3BC7F9B5-8C19-45D7-A1B8-E86971FAF9F2%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/9dbc00d4-5db3-4ddd-b042-801a478c0fb5%40email.android.com.
