> On 20 Nov 2019, at 08:42, Jan Voskuil <[email protected]> wrote: > > The example is not correct but I created a small example that is. TBC works > fine with punning. Of course :myCar rdf:type :TeslaModelS :type :CarModel > means that :myCar does not inherit any properties from :CarModel. > > <Capture.PNG> > > > > On Tuesday, November 19, 2019 at 8:20:34 PM UTC+1, Jan Voskuil wrote: > Thanks David, you are right. I did follow some courses on possible world > semantics, Montague semantics, higher order logics and the like, and although > this is now ancient history (for me) I should have known and phrased my > concerns differently. In any case thanks for the references, these are highly > relevant to the discussions I am currently taking part in: Linked Building > Data community and a related Dutch standard that Michel is working on a lot. > > I guess, though, that the problem is not DL vs FOL but type theory. The spec > to which you refer in your original comment says: > The OWL 2 Direct Semantics treats the different uses of the same name as > completely separate, as is required in DL reasoners. > Does the same not also hold for FOL-reasoners?
Nope. There are, of course, flavours of FOL reasoners too, but classes having classes as members is supported and the thing in question is the same thing whether a class or member - if that’s the question. It’s just set theory where sets are allowed to be members of sets. > > So <mountain>-the-concept and <mountain>-the-class are different objects. > Same for your example > > :x rdf:type :Eagle rdf:type :Species rdf:type owl:Class > > Eagle-the-species is a different thing than eagle-the-individual, so from > these statements it cannot be concluded that :x is an instance of something > that, in turn, is a species. And if that spurious conclusion is NOT intended, > then why not use two different names? > > Or would a FOL-reasoner infer the intended conclusion? I am beginning to have > doubts so I am curious. I’m confused by that the “it cannot be concluded” comment on: > :x rdf:type :Eagle rdf:type :Species rdf:type owl:Class :x is an :Eagle :Eagle is a :Species :Species is a owl:Class clearly asserts that “:x is an instance of something that, in turn, is a species” as far as FOL interpretations are concerned. There is no inference to be made wrt x: itself. :Eagle a owl:Class would be inferred though. Maybe I missed the real question? > > And, contrary to may earlier statements about tools going berserk, TBC > handles punning quite nicely. So I retract that. So when you open the > infamous DCTERMS ontology and open it in TBC, you will find that AgentClass > is defined as a Class and a subClassOf Class. Instances of AgentClass are > neatly shown as classes not individuals, althought they are both (but not at > the same time). That said, I keep having a rather queasy feeling when I see > this. > > > > Blending a domain model with the modelling language itself is indeed something to question (e.g. It may be correct but is it necessary? Does it cause anyone or any engine a problem?). It may be it’s there to support query or some other not-100%-clear usage, so hard to be definitive. > Of course all this is not intended to suggest that FOL does not solve real > problems. It does, and so do more powerful logical systems. > > And I do remember the discussions we had in which you propose to treat > different levels of modelness in separate graphs. That would also be an > instance of punning, but one in which one can systematically separate out the > different meanings in contexts that are explicitly marked as different. Still > a lot to process, but at least it becomes tractable what is what when. > > My general penchant is that SHACL offers a wealth of tactics to do > metamodeling in a much more elegant way than with OWL (let alone punning). A > good example was pointed out by Holger to me earlier today: dash:composite. I > believe SHACL is seriously underused in tackling the hairier problems in > information modelling on the semantic web. Agree SHACL’s a nice language. It’s focus is data constraint rather than inference. That’s often not a problem because “adding logically inferred data to existing data” is a less common business need than “validating my existing data, and only that data”. FWIW UML has a very similar construct to dash:composite, so it’s definitely a useful idea. Cheers, David > > On Tuesday, November 19, 2019 at 5:54:34 PM UTC+1, David Price wrote: > > >> On 19 Nov 2019, at 15:24, Jan Voskuil <[email protected] <>> wrote: >> >> A very late after-burner (I am currently involved in similar discussions and >> stumbled upon this thread by accident): >> Have a look at Uschold's "Demystifying OWL". It is a good read, especially >> the two pages on punning. >> While there is little to add to what Irene and David have said, I think it >> is important to stress that when people say things like "I have a set of >> triples, and these imply OWL Full", what really is being said is that there >> is a deep and serious problem with the model being used. OWL Full does not >> solve these problems, nor does it cause interesting things to happen. It >> only guides an OWL-inferencer around the underlying problems, so that it >> does not break down. The original intention of the underlying model is not >> achieved, however. Introspective tools will not behave as expected. Irene's >> example about the BMW 240i is hard in any formal language, because of type >> theory being counter-intuitive. There is nothing one can do about that. >> Instead of trying to out-smart the semantics of RDF, it is most often better >> to bite the bullet and solve the issue in the model itself --- and accept >> the added complexity. >> > > Hi Jan, > > Personally, I think that characterisation goes a bit too far although the > core sentiment is a good approach. > > Technically, all "OWL Full” really means is that the model uses logic that > is, for example, based in First Order Logic [1] rather than in Description > Logic [2]. Using DL often means the modeller has chosen “decidability” over > “representational capability” wrt their model. That’s fine if DL is > sufficient to model your domain of interest. But, what if it’s not? > > There are certainly cases where the use of first order logic models and > engines have solved real-world problems. > > I imagine most folks don’t know that “The relational model (RM) for database > management is an approach to managing data using a structure and language > consistent with first-order predicate logic,” (quote from > https://en.wikipedia.org/wiki/Relational_model > <https://en.wikipedia.org/wiki/Relational_model>) > > There’s even an ISO standard logic language supporting for those cases - > Common Logic [3] is an ISO standard that “provide for the expression of > arbitrary first-order logical sentences”. > > There are also standard data models, ISO 15926-2 [4] for example, that are > based in higher-than-DL order logic (full disclosure, with previous employers > I worked in ISO on 15926 and ISO 10303 STEP). > > I agree that there are many, many, many “bad” models in industry. However, > there are plenty of quality models that use logic higher than DL - they just > require more expertise to create and use (e.g. logicians may be needed in the > project). I happen to have studied math and have been surprised at times to > find ontologist/modelers who don’t understand any of this stuff because they > never studied set theory or logic. These more complex ideas require some > background education/knowledge in order to use them properly. However, I’m > sure you know the quote: Everything Should Be Made as Simple as Possible, But > Not Simpler. > > Apologies for the long reply and all the links. Just something to which I > happen to have had quite a bit of exposure, although am not truly an expert, > as I spent a lot of time debating academics and logicians in ISO-land when > working for IBM. > > Cheers, > David > > [1] ISO/IEC 24707:2018. Information technology — Common Logic (CL) — A > framework for a family of logic-based languages > > See https://www.iso.org/standard/66249.html > <https://www.iso.org/standard/66249.html> > > [2] First-order Logic > > Seehttps://en.wikipedia.org/wiki/First-order_logic <> > > [3] Description Logic > > See https://en.wikipedia.org/wiki/Description_logic > <https://en.wikipedia.org/wiki/Description_logic> > > [4] ISO 15926-2:2003. Industrial automation systems and integration — > Integration of life-cycle data for process plants including oil and gas > production facilities — Part 2: Data model > > See https://www.iso.org/standard/29557.html > <https://www.iso.org/standard/29557.html> > >> On Tuesday, October 8, 2019 at 5:31:08 PM UTC+2, Bohms, H.M. (Michel) wrote: >> >> In: >> >> https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html >> <https://www.w3.org/2006/07/SWD/SKOS/skos-and-owl/master.html> >> >> its is said: >> >> “ >> >> To illustrate these patterns, let's start with the following semi-formal >> conceptualisation: >> >> ex:mountains rdf:type skos:Concept; >> >> skos:prefLabel "Mountains"@en. >> >> >> ex:himalayas rdf:type skos:Concept; >> >> skos:prefLabel "Himalayas"@en; >> >> skos:broader ex:mountains. >> >> >> ex:everest rdf:type skos:Concept; >> >> skos:prefLabel "Everest"@en; >> >> skos:broader ex:himalayas. >> >> Overlay SKOS with OWL >> >> In this pattern, we use OWL to overlay additional semantics on the same >> vocabulary, e.g. by adding the following triples: >> >> ex:mountains rdf:type owl:Class. >> >> >> ex:himalayas rdf:type owl:Class; >> >> rdfs:subClassOf ex:mountains. >> >> >> ex:everest rdf:type ex:himalayas. >> >> If the two sets of triples are merged, then this pattern necessarily leads >> to an OWL Full representation, because an instance of skos:Concept might >> also be an instance of owl:Class. >> >> >> “ >> >> >> Is the red statement really true? And if yes, is it really an issue here? >> >> >> (maybe it was under owl1 but under owl2 not different?) >> >> >> thx for advice, Michel >> >> >> >> >> >> Dr. ir. H.M. (Michel) Böhms >> Senior Data Scientist >> >> >> T +31888663107 >> M +31630381220 >> E [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> >> >> >> >> <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] <>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/topbraid-users/f0949410-8879-47a8-96a7-535938ec117b%40googlegroups.com >> >> <https://groups.google.com/d/msgid/topbraid-users/f0949410-8879-47a8-96a7-535938ec117b%40googlegroups.com?utm_medium=email&utm_source=footer>. > > UK +44 (0) 7788 561308 > US +1 (336) 283-0808 > > > -- > 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/c471470a-12cd-436d-ba19-f5e46ba76e05%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/c471470a-12cd-436d-ba19-f5e46ba76e05%40googlegroups.com?utm_medium=email&utm_source=footer>. > <Capture.PNG> UK +44 (0) 7788 561308 US +1 (336) 283-0808 -- 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/6D353054-2444-4439-9E0C-B422415E8893%40topquadrant.com.
