Hi Irene, Holger I see your points but… ☺…
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 ☺ Especially because I am still on the more >>> purest line (I just learned…always thought there was only one line ☺) >>> 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 On 6/24/2014 7:59, Irene Polikoff wrote: 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]> [mailto:[email protected]] On Behalf Of Bohms, H.M. (Michel) Sent: Monday, June 23, 2014 9:40 AM To: [email protected]<mailto:[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 [email protected]<mailto:[email protected]> Location<http://www.tno.nl/locaties/DTM> [cid:[email protected]]<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]> [mailto:[email protected]] On Behalf Of Holger Knublauch Sent: zondag 22 juni 2014 11:10 To: [email protected]<mailto:[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 [email protected]<mailto:[email protected]> To unsubscribe from this group, send email to [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> To unsubscribe from this group, send email to [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> To unsubscribe from this group, send email to [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> To unsubscribe from this group, send email to [email protected]<mailto:[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]<mailto:[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.
