domain ' inheritance'

[Bohms, H.M. (Michel)]

Hi Holger, Scot

 

We are very eager to get some info on our earlier posted issue:

 

“

When I define a class A and a subclass A1

And a property P with domain A

In tbc when instantiating A1 the property is shown. Why is that?

My assumption is that this property is not ‘inherited’ to its subclass.

Is that right?

“

Thx very much for your consideration. In NL were working on a national modeling guide in which linking classes <> properties is an important issue (typically difficult/different for many involved since it differs from tradiotional modeling approaches).

Thx Michel

 

Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.

 

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.

[Bob DuCharme]

Hi Michel,

The subclass relationship in RDF is about subsets, so if A1 is a subset of A, then members of A1 are members of A. If the user interface knows that P has domain A, it includes P on forms for A1 instances because those are also instances of A. 

For example, in the kennedys model included with TopBraid Composer, the  kennedys:parent property has an rdfs:domain of kennedys:Person and kennedys:Patriarch is a subclass of kennedys:Person, so the kennedys:parent property appears on the form for the the kennedys:JosephKennedy instance of kennedys:Patriach.

I wouldn't consider this to be inheritance, which I think of more in terms of inheritance of instance behavior, but instead as the use by applications such as TopBraid Composer (and other applications built with the TopBraid platform) of the model to drive interface behavior. 

Bob DuCharme

TopQuadrant

--
-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.
To post to this group, send email to
topbrai...@googlegroups.com
To unsubscribe from this group, send email to
topbraid-user...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en
---
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.
For more options, visit https://groups.google.com/d/optout.

[Irene Polikoff]

Yes, there is really no notion of inheritance in RDFS or OWL, just the notion of inference.

 

Consider the following. If a property P is in the domain of class A, it doesn’t mean that every instance of A must have a value for P. Some may and some may not. It only means that if an instance has a value for property P, it must be a member of class A. We show P in the form for instances of A because an instance of A is ‘likely’ to have a value for P.

 

This also means that there is some subclass of A that can be said to be in the domain of P. We don’t know if A1 is such subclass – we can’t infer this for sure, but it very well could be. In fact, it is also possible and even likely that all subclasses of A can be said to be in the domain of P. With this, the form for instances of A1 shows its ‘likely’ properties, including P.

[Holger Knublauch]

Thx very much for your consideration. In NL were working on a national modeling guide in which linking classes <> properties is an important issue (typically difficult/different for many involved since it differs from tradiotional modeling approaches).

In my *personal* opinion you may also chose to simply ignore the official RDFS semantics and apply the intuitive and mainstream interpretation of rdfs:domain as a way to "attach" a property to a class, rdfs:range to restrict the values and rdfs:subClassOf as inheritance. While officially this is not entirely correct, it will most likely have no negative side effects to start with that (object-oriented) point of view for your ontologies. After more than ten years of semantic technology standards, the official formal semantics have not become widely used and in my *personal* opinion this is never going to change either. See the increasing popularity of JSON-LD and "simple" ontologies like schema.org to see where this is going.

Holger

[David Price]

Also *personal* opinion :-)

The main characteristics of OO (i.e.polymorphism, encapsulation, information hiding) are really not applicable to OWL as they are specifications about behaviour, not data. OWL is data with no defined behaviour and so not really OO IMPO. I guess you can think of OO inheritance is a cousin of subset+inference and, as Holger said, in many case the practical differences are minimal. However, there are other cases where using OWL can be very non-OO e.g. 1) no concept of a required "type" so an individual can be a member of classes in very different ontologies and 2) OWL individuals are not required to have a pre-defined "type" and you can then infer its type(s) based on a property with domain or range being used with that individual.

Note that it's been my experience when creating OWL ontologies, regardless of their use, that it's better to think in terms of subset rather than inheritance. Drawing Venn diagrams is usually the best way to understand data, for example do the necessary analysis to separate subClassOf from partOf relationships between things.

Cheers,

David

UK +44 7788 561308

US +1 336 283 0606

[Jack Hodges]

All aspects of object orientation (encapsulation, inheritance, and polymorphism) apply equally to class members and methods. In OWL/RDF we have class inheritance but we don't have the structure of a class such as we do in programming languages. The triple of S-P-O is a very simple structure, so there isn't any structure to encapsulate nor is there structure to use differently in different contexts (polymorphism). I mention this not to negate anything you have said but because some of the things you said about OO and OWL/RDF aren't completely clear. So to be clear, when we define restrictions on a class (e.g., that some class B has a restriction of predicate p), that restriction is not inherited on a subclass B1 of B. True?

On the other hand, when we define a predicate p with a domain of A, any subclass A1 of A will apply equally as a domain of p. True?

These two contexts are different.

Jack

[Irene Polikoff]

Actually, it is the other way around. Restriction on a class applies to all of its subclasses, domain or range declarations don't necessarily apply to all subclasses. 

This is according to the standard semantics. However, in practical use, people typically only say that a property is in a domain or a range of a class if it is true for all it's subclasses. This is a point Holger is making.

Sent from my iPhone

[Irene Polikoff]

Typo, I meant the domain of the property.

Not sure what you mean by subproperties humor ring re-use. People often leave the parent property without either a domain or range using it primarily for grouping to assist querying.

Sent from my iPhone

On Jun 23, 2014, at 4:15 AM, "Bohms, H.M. (Michel)" <michel...@tno.nl> wrote:

Dear all, thx for all your inputs.

 

I understand that all restrictions on a class are true for all its subclasses.

 

But indeed,  a domain, is a restriction for a property. (Irene, why do you talk about “in the domain of a class”…isn’t it better to talk about the domain of a property?)

 

So I understand now that this is not necc. true for all subclasses (only “likely” and hence the GUI things..).

 

(I assume now that it DOES effect on all subproperties (so that the domain is also true for all subproperties, hampering potential reuse (of properties) etc.))

 

Gr Michel

 

Dr. ir. H.M. (Michel) Bohms Sr. Research Scientist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E michel...@tno.nl Location   <image001.gif>

[Bohms, H.M. (Michel)]

Hi Holger,

 

Somehow YOUR reply came in my spam box, so my response is a bit late,

 

But what an interesting personal view!

 

Still I think we run into formal problems ignoring the official RDFS semantics.

 

Informal expectations might this way conflict with reasoners output etc.

 

Informally “Adding properties to class” by formally adding “classes to properties (ie domain definitions)” is IMHO a recipe for problems.

 

If you do this and then say the properties are somehow “inherited” to the subclasses I think things get even worse.

 

(I was triggered on this issue earlier when using your EVN approach where properties are depicted as belonging to a class in case of domains specified).

 

So, when you say “not entirely correct” I would rather say “entirely incorrect”

 

But ok, this is just MY personal view, gr Michel

 

Dr. ir. H.M. (Michel) Bohms Sr. Research Scientist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 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.

 

From: topbrai...@googlegroups.com [mailto:topbrai...@googlegroups.com] On Behalf Of Holger Knublauch
Sent: zondag 22 juni 2014 11:10
To: topbrai...@googlegroups.com
Subject: Re: [topbraid-users] domain ' inheritance'

 

Thx very much for your consideration. In NL were working on a national modeling guide in which linking classes <> properties is an important issue (typically difficult/different for many involved since it differs from tradiotional modeling approaches).

In my *personal* opinion you may also chose to simply ignore the official RDFS semantics and apply the intuitive and mainstream interpretation of rdfs:domain as a way to "attach" a property to a class, rdfs:range to restrict the values and rdfs:subClassOf as inheritance. While officially this is not entirely correct, it will most likely have no negative side effects to start with that (object-oriented) point of view for your ontologies. After more than ten years of semantic technology standards, the official formal semantics have not become widely used and in my *personal* opinion this is never going to change either. See the increasing popularity of JSON-LD and "simple" ontologies like schema.org to see where this is going.

Holger

--

-- You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN.

[Bohms, H.M. (Michel)]

Typo, I meant the domain of the property.

 

>>ok, now FULLY clear

 

Not sure what you mean by subproperties humor ring re-use. People often leave the parent property without either a domain or range using it primarily for grouping to assist querying.

 

>> I just meant that WHEN you define a domain for a property it IS valid for all its subproperties. And hence typically domains are often adviced to be avoided when an ontology is likely to be extended by others or in time.

 

 

Gr Michel Bohms

Ps I don’t understand your “…by subproperties humor ring re-use”

 

Sent from my iPhone

[Bohms, H.M. (Michel)]

Dear all, thx for all your inputs.

 

I understand that all restrictions on a class are true for all its subclasses.

 

But indeed,  a domain, is a restriction for a property. (Irene, why do you talk about “in the domain of a class”…isn’t it better to talk about the domain of a property?)

 

So I understand now that this is not necc. true for all subclasses (only “likely” and hence the GUI things..).

 

(I assume now that it DOES effect on all subproperties (so that the domain is also true for all subproperties, hampering potential reuse (of properties) etc.))

 

Gr Michel

 

Dr. ir. H.M. (Michel) Bohms Sr. Research Scientist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 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.

 

From: Irene Polikoff [mailto:ir...@topquadrant.com]

Sent: zondag 22 juni 2014 17:22
To: topbrai...@googlegroups.com
Cc: Bohms, H.M. (Michel)
Subject: Re: [topbraid-users] Re: domain ' inheritance'

 

Actually, it is the other way around. Restriction on a class applies to all of its subclasses, domain or range declarations don't necessarily apply to all subclasses. 

[Irene Polikoff]

It is a fact that RDFS was not designed as a vocabulary for specifying classes in an object oriented way, meaning as in ‘defining a template for instances’. It was designed to support inferences for ‘knowledge discovery’ - taking either an un-typed resource and deriving its type or a resource that doesn’t have all the type information and inferring additional type triples. In other words, it was designed to support classification.

 

In practical use, however, people found that they needed a simple to use vocabulary for specifying class properties (simpler than OWL) and they started using RDFS that way. With rare exceptions, this is a much more common RDFS use case than the one that is about inferring class membership.

 

So, the purist view point is technically correct, but practically - not so much. What is happening in real use, now that we all have more experience with using the standards to support business requirements, has to trump what was planned and envisioned in a speculative way when the standard was first developed. This kind of evolution happens all the time with standards and with technologies in general.

[Holger Knublauch]

Exactly, and even in OWL the vast majority of people use owl:Restrictions to mean "constraint" instead of "inference". The standards are in this respect neither intuitive nor do they address the more common use cases, so in a sense they have failed to meet the real-world test.

Again, this is just my personal view based on 10 years of experience in this field, and moving from university to industry. The literature is of course full of papers that contradict with this view point. Some of this contradiction is historic though and practical application has moved away from academic theory.

Decide for yourself whether compatibility with some specific OWL reasoners is more important for your project than a useable and intuitive user interface.

Holger

[Bohms, H.M. (Michel)]

Hi Irene, Holger

 

I see your points but… J…

 

Subject: Re: [topbraid-users] domain ' inheritance'

 

Exactly, and even in OWL the vast majority of people use owl:Restrictions to mean "constraint" instead of "inference". The standards are in this respect neither intuitive nor do they address the more common use cases, so in a sense they have failed to meet the real-world test.

 

>>>if we just treat inference rules as constraints why would we ever bother to develop SPIN (and ways to automatically treat inference rules as such)

Again, this is just my personal view based on 10 years of experience in this field, and moving from university to industry. The literature is of course full of papers that contradict with this view point. Some of this contradiction is historic though and practical application has moved away from academic theory.

 

>>> I also see your point here: and its actually the reason I was a bit “shocked” to hear you view J Especially because I am still on the more purest line (I just learned…always thought there was only one line J) trying to get people appreciate more OWA and its consequences…(because I believe the “academic” interpretation not only has its disadvantages but also its clear advantages like improved flexability

I feel a bit like if we’re going to treat rdf/rdfs/owl in a bit informal way (potentially different informally ways) we’re losing the benefits all together and better go back to UML, XSD, EXPRESS, NIAM etc.

Decide for yourself whether compatibility with some specific OWL reasoners is more important for your project than a useable and intuitive user interface.

 

>>hard to choose, both are important….anyway, thx for the discussion! Michel

[Holger Knublauch]

On 6/24/2014 17:46, Bohms, H.M. (Michel) wrote:

if we just treat inference rules as constraints why would we ever bother to develop SPIN (and ways to automatically treat inference rules as such)

Not sure what you mean. SPIN has an explicit distinction between constraints and inferences, and both have separate use cases that have proven to be important and suitable for practical applications. In fact SPARQL is far more expressive than OWL and therefore covers more relevant use cases such as computations and literal manipulations. OWL does have some suitable use cases for inferencing as well (mainly classification problems), but it was not designed to be a constraint language. However, the latter is what the majority of people seem to expect the OWL vocabulary to mean, despite years of training and marketing.

I feel a bit like if we’re going to treat rdf/rdfs/owl in a bit informal way (potentially different informally ways) we’re losing the benefits all together and better go back to UML, XSD, EXPRESS, NIAM etc.

No I don't agree with that. Even if you would remove the whole OWL DL aspect, RDF/OWL would still have many advantages over the technologies that you mention. In particular it provides a means to express globally linked data models where everything can be addressed with a URI. In contrast, XML and UML objects do not have such a notion of identity. Furthermore, RDF/OWL is extensible and self-describing - classes are data on their own. None of this requires the model-theoretic semantics that for some reason have been developed in conjunction with the RDF/OWL standards. It would indeed be straight-forward to redesign a standard that reuses most of the system vocabulary (URIs such as owl:Restriction) from the current RDF/OWL but redefines their meaning to be in alignment with mainstream "object" models such as JSON. Most of the published ontologies out there would still be perfectly useable with such a W3C standard, and a lot of historic ballast could be moved into the parallel universe of DL and other theoretical interpretations of that vocabulary.

(Sorry for drifting a bit off-topic from the original question that was really just about a tiny aspect of the direction in which rdfs:domain/range statement should be interpreted!)

Cheers,
Holger

[Bohms, H.M. (Michel)]

Hi Holger, see after >>>

 

Dr. ir. H.M. (Michel) Bohms Sr. Research Scientist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 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.

 

From: topbrai...@googlegroups.com [mailto:topbrai...@googlegroups.com] On Behalf Of Holger Knublauch
Sent: woensdag 25 juni 2014 4:27
To: topbrai...@googlegroups.com
Subject: Re: [topbraid-users] domain ' inheritance'

 

On 6/24/2014 17:46, Bohms, H.M. (Michel) wrote:

if we just treat inference rules as constraints why would we ever bother to develop SPIN (and ways to automatically treat inference rules as such)

Not sure what you mean. SPIN has an explicit distinction between constraints and inferences, and both have separate use cases that have proven to be important and suitable for practical applications. In fact SPARQL is far more expressive than OWL and therefore covers more relevant use cases such as computations and literal manipulations. OWL does have some suitable use cases for inferencing as well (mainly classification problems), but it was not designed to be a constraint language. However, the latter is what the majority of people seem to expect the OWL vocabulary to mean, despite years of training and marketing.

 

>>>clearly I see the benefit of more power. I was more thinking about the same-power stuff, automatically trasnfrom/interpret. restrictions to SPIN so that they can be treated as constraint (and in the guid you can have validation of data etc.).

I feel a bit like if we’re going to treat rdf/rdfs/owl in a bit informal way (potentially different informally ways) we’re losing the benefits all together and better go back to UML, XSD, EXPRESS, NIAM etc.

No I don't agree with that. Even if you would remove the whole OWL DL aspect, RDF/OWL would still have many advantages over the technologies that you mention. In particular it provides a means to express globally linked data models where everything can be addressed with a URI. In contrast, XML and UML objects do not have such a notion of identity. Furthermore, RDF/OWL is extensible and self-describing - classes are data on their own. None of this requires the model-theoretic semantics that for some reason have been developed in conjunction with the RDF/OWL standards. It would indeed be straight-forward to redesign a standard that reuses most of the system vocabulary (URIs such as owl:Restriction) from the current RDF/OWL but redefines their meaning to be in alignment with mainstream "object" models such as JSON. Most of the published ontologies out there would still be perfectly useable with such a W3C standard, and a lot of historic ballast could be moved into the parallel universe of DL and other theoretical interpretations of that vocabulary.

(Sorry for drifting a bit off-topic from the original question that was really just about a tiny aspect of the direction in which rdfs:domain/range statement should be interpreted!)

>>ok, see your point. I was more thinking about actual benefits of the things you want to do away with as ballast to DL….

Gr Michel

Cheers,
Holger