Irene I have the feeling we are not understanding each other.
I will try to go bottom up. For a standard we are trying to provide a pattern for (complex) property modelling that enables the modelling of meta-properties on instance level (height123 measuredby Irene) and definition level (height hasQuantityKind Length) Besides that we also want to provide a simple variant using directly the language constructs, hence in owl:owl:Datatype property (sometimes people are not interested in meta-data at all). We now have three options on the table: Option 1 is currently proposed in standard (influenced by the current way of modelling properties in IFC of buildingSmart International). Essence of complex: we define a class Property and a class PropertyDef. The first one is instantiated with height123, the second with height. The latter is related via an objectproperty to the def. The first one is what we call objectification to compensate for current RDF power. This is also what W3C LBD OPM calls level “2”(1xobjectification) Option 2 was proposed by a Dutch software vendor called Semmtech. Essence of complex: skip the PropertyDef. Simply refer via the hasPropertyDef to the simple variant! But than the meta data has to be put at a datatype property (hencfe my questions on use of reasoners etc.) Option 3 was proposed by Taxonic/Jan. Essence: also skip PropertyDef and subclass Property into Height and specify def.level metadata as constraints (esp. in shacle). Technically they are all possible but having pro and cons wrt: - use of reasoners - reuse of existing language elements - simplicity - etc. etc. And yes, by even asking these questions I would qualify as “creators do not understand the Semantic Web standards and the modeling patterns/options available to them” (since I did not start from another modelling language) but I happily run this risk hoping for an open world interpretation allowing some third category 😊 Michel Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E [email protected]<mailto:[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> [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. Van: [email protected] <[email protected]> Namens Irene Polikoff Verzonden: Thursday, November 21, 2019 1:59 PM Aan: [email protected] Onderwerp: Re: [topbraid-users] Re: combining owl and skos Michel, I am not aware of any real life, production applications that use DL reasoning. Thus, I do not see the question about what may be inferred by such reasoner, as very practical. On the other hand, the meaning of OWL and RDFS statements (how they should be interpreted) is defined in terms of inference entailment. DL vs Full is not really that important. The meaning does not change. If someone builds a custom application that works against a model they develop, they control the behavior of that application and can make it interpret the model anyway they decide. If they expect some off the shelf software to be able to work well with such models and interpret the model and data in the way they think it should be interpreted, they may be disappointed. If they expect others, outside of their group, to understand the meaning of their model and data, they may also be disappointed. They may also run into some walls and create unnecessary complexities that will require various inventions, solutions and workarounds. I agree with the points made by Jan. Further, I believe in most cases models like this are created because 1) creators do not understand the Semantic Web standards and the modeling patterns/options available to them 2) creators starting point was a model built using some other modeling framework/language that did not have the same options and semantics as let’s say OWL or even RDF. They do a one to one conversion without rethinking how it may be different given a different semantic system. On Nov 21, 2019, at 3:03 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <[email protected]<mailto:[email protected]>> wrote: Hi Irene, Wrt your “To be clear, I would not recommend this approach to data modeling. I also have to admit that I find this discussion pretty esoteric and largely irrelevant.” We find this pattern/need very often in practice (multi-level typing). Catalogue products beings instances that are instantiated again for a client, properties defined with meta-data, instantiated again for actual properties of things, etc. etc. People use very different ways of dealing with it using punning, rdf:Property as range, objectproperties iso rdf:type having similar semantic intentions etc. etc. So I guess its important to know for certain variants what is actually inferred or not etc. I was glad the issue was brought up (again) by Jan. The start of the issue was actually a question of some clients on how to best combine say RDFS/OWL and SKOS since sometimes the thing modelled then could be both an instance and a class and the w3c spec sayd his would lead to owl full which might have been true for owl1 but not for owl2. Greetings Michel Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E [email protected]<mailto:[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> <image001.gif><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. Van: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Namens Irene Polikoff Verzonden: Thursday, November 21, 2019 1:25 AM Aan: [email protected]<mailto:[email protected]> Onderwerp: Re: [topbraid-users] Re: combining owl and skos RDFS says: rdf:type rdfs:range rdfs:Class. Given :x a :Eagle. :Eagle a :Species. :Species a owl:Class. A tool that implements RDFS inferencing will conclude :Eagle a rdfs:Class. :Species a rdfs:Class. If you add OWL into the mix, you may get :Species rdfs:subClassOf owl:Thing. :Eagle a owl:Thing. owl:Nothing rdfs:subClassOf :Eagle. Possibly, :Eagle a owl:NamedIndividual. I believe it has the same class extension as owl:Thing. I can’t think of any other inferences entailed by the 3 triples above. To be clear, I would not recommend this approach to data modeling. I also have to admit that I find this discussion pretty esoteric and largely irrelevant. On Nov 20, 2019, at 8:23 AM, dprice <[email protected]<mailto:[email protected]>> wrote: Because of things like “owl:Thing rdf:type owl:Class”, owl:disjointWith rdfs:domain/rdfs:range owl:Class, etc. I think it's owl:Class, but I’ve never looked at a specific reasoner’s behaviour in detail. May even vary from reasoner to reasoner. Cheers, David On 20 Nov 2019, at 12:35, Irene Polikoff <[email protected]<mailto:[email protected]>> wrote: I would think rdfs:Class, not owl:Class. On Nov 20, 2019, at 4:48 AM, dprice <[email protected]<mailto:[email protected]>> wrote: Everything that is the rdfs:range of rdf:type is by-definition an owl:Class. -- 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/141FBB70-87C7-4838-8187-7355B2559387%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/141FBB70-87C7-4838-8187-7355B2559387%40topquadrant.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/59C5654B-C504-4DEA-B6C0-9B589B8158BD%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/59C5654B-C504-4DEA-B6C0-9B589B8158BD%40topquadrant.com?utm_medium=email&utm_source=footer>. -- 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/81C29C1A-50BD-4AFA-A7EF-8C85428056A4%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/81C29C1A-50BD-4AFA-A7EF-8C85428056A4%40topquadrant.com?utm_medium=email&utm_source=footer>. -- 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/fc4a73c7bab54b9fb948280f0a763673%40tno.nl<https://groups.google.com/d/msgid/topbraid-users/fc4a73c7bab54b9fb948280f0a763673%40tno.nl?utm_medium=email&utm_source=footer>. -- 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/BC5A0ABB-B03F-4421-9264-1B64422D746F%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/BC5A0ABB-B03F-4421-9264-1B64422D746F%40topquadrant.com?utm_medium=email&utm_source=footer>. -- 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/3a4b92159747497e8d6f810bce86c3b7%40tno.nl.
ALT-ComplexPropertyPatterns.docx
Description: ALT-ComplexPropertyPatterns.docx
