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. From: [email protected] [mailto:[email protected]] On Behalf Of Bohms, H.M. (Michel) Sent: Monday, June 23, 2014 9:40 AM To: [email protected] Subject: RE: [topbraid-users] domain ' inheritance' 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 <mailto:[email protected]> [email protected] <http://www.tno.nl/locaties/DTM> Location <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. From: [email protected] [mailto:[email protected]] On Behalf Of Holger Knublauch Sent: zondag 22 juni 2014 11:10 To: [email protected] 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. To post to this group, send email to <mailto:[email protected]> [email protected] To unsubscribe from this group, send email to <mailto:[email protected]> [email protected] For more options, visit this group at <http://groups.google.com/group/topbraid-users?hl=en> 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 [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout. -- -- 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
