or-domains

[Bohms, H.M. (Michel)]

 

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’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 michel...@tno.nl Location   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.

 

 

[Richard Cyganiak]

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 <topbrai...@googlegroups.com> 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’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 michel...@tno.nl Location

<image001.gif>

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 topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/c1a3101dbb0442a0bf31fc8f08bfb692%40tno.nl.

[Bohms, H.M. (Michel)]

 

Hi Richard, very clear! Thx.

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/204378D0-C0AA-4EF6-B41A-D72D816726A5%40topquadrant.com.

[Steven Michael Folsom]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/204378D0-C0AA-4EF6-B41A-D72D816726A5%40topquadrant.com.

[Irene Polikoff]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/FB8617FD-6C8D-4387-B049-D694A0443586%40cornell.edu.

[Bohms, H.M. (Michel)]

 

Guess so...

 

Although the question was in a situation of “RDFS-only”.

 

In OWL we could use union classes as domain (besides superclasses).

And in SHACL again other constructs...(implicitly via sh:property or explicitly via target class)

 

michel

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

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: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Steven Michael Folsom
Verzonden: Tuesday, January 7, 2020 4:33 PM
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] or-domains

 

Is this a case where a SHACL NodeShape/s with a targetClass/es and PropertyShapes would be helpful?

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/FB8617FD-6C8D-4387-B049-D694A0443586%40cornell.edu.

[Bohms, H.M. (Michel)]

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?

 

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 michel...@tno.nl Location

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: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Irene Polikoff
Verzonden: Tuesday, January 7, 2020 5:11 PM
Aan: topbrai...@googlegroups.com
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. 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/E8961EBD-5D52-47E2-9F15-0CD349F69CE8%40topquadrant.com.

[dprice]

IMO this is not a best practice modelling structure from the point of view of reuse. "hasInterior rdfs:range SpatialRegion" seems a general property that other classes in a using ontology might find useful. I would delete the domain here and use restrictions in the domain classes if using OWL. If using RDFS then I’d do as Richard suggested and make a superclass, which using ontologies could then also subclass thus encouraging reuse.

FWIW the meaning of hasInterior being an inverse of itself is confusing to me. How can x is interior to y AND y is interior to x both be true?

Cheers,

David

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/c03d58686bc7441caab867774773e051%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

Thx, indeed for flexibility I best remove the domains.

 

Inverse: thx for spotting the typo, should be:

 

bs:hasInterior

  a owl:ObjectProperty ;

  rdfs:domain [

      a owl:Class ;

      owl:unionOf (

          bs:PhysicalObject

          bs:Activity

        ) ;

    ] ;

  rdfs:range bs:SpatialRegion ;

  owl:inverseOf bs:isInteriorOf ;

  skos:prefLabel "has interior"@en ;

  skos:prefLabel "heeft inwendige"@nl ;

.

 

 

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist

T +31888663107 M +31630381220 E michel...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/37A3E8E1-81C0-453F-A848-28F64A4C79AF%40topquadrant.com.

[Irene Polikoff]

On Jan 8, 2020, at 2:34 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> 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 michel...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/c03d58686bc7441caab867774773e051%40tno.nl.

[Bohms, H.M. (Michel)]

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 <ir...@topquadrant.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/3BC7F9B5-8C19-45D7-A1B8-E86971FAF9F2%40topquadrant.com.