Hi Michel, Just remembered that the ISO 15926-12 ontology is available online, in case you would like to compare that with the OPM.
https://standards.iso.org/iso/ts/15926/-12/ed-1/en/tech/ontology/ <https://standards.iso.org/iso/ts/15926/-12/ed-1/en/tech/ontology/> Note that there’s an “examples” folder with a few simple cases. FWIW I had a peek at OPM and it seems like a reasonable approach to what some call the “3.5D” solution to properties changing over time (i.e. adding timestamps, etc to associations). However, the way values and UoM is handed in that CDT ontology seems very counterproductive to me. It greatly limits the RDF-based tools that can be used which seems like an unreasonable trade-off vs one more triple to store the UoM when you’re already reifying the property value anyway. Cheers, David > On 3 Mar 2019, at 10:58, 'Bohms, H.M. (Michel)' via TopBraid Suite Users > <[email protected]> wrote: > > > > Verzonden van mijn Android-telefoon via TouchDown (www.symantec.com) > > -----Original Message----- > From: Michel Böhms [[email protected]] > Received: zondag, 03 mrt. 2019, 11:55 > To: Bohms, H.M. (Michel) [[email protected]] > Subject: Re: FW: [topbraid-users] Classlevel properties? > > Hi David, Irene, Richard > > FWIW saying “owl-wise not ok” is inaccurate. To be accurate you need to say > "OWL DL (aka Direct Semantics)-wise not ok”. OWL Full (aka RDF-based > Semantics) does not mind. > > Yep, sorry, I meant worst case, so would it be ok owl-full. Seems now from > your answers, yes but do not exepct to much from reasoning and do not assume > semantics from class to instances. Think I can live with that! (and indeed > partition before reasoning etc.). Most important is being able to store and > query. > The use case fyi is the following: there is an iso in development: > > "ISO/DIS 23386 <https://www.iso.org/standard/75401.html?browse=tc> [Under > development] > Building information modelling and other digital processes used in > construction -- Methodology to describe, author and maintain properties in > interconnected dictionaries " > > that we want to give a "linked data-binding" in CEN TC442/WG4/TG3. > > This could nicely be done reusing the W3C LBD (Linked Building Data) group's > OPM ontology (Ontology for Property Management). This opm has 3 levels: > - L1-simple: direct use of owl datatype properties > - L2-more complex, properties as instances of classes > - L3-even more complex: also property values (states) as instances (ie double > 'objectivication') > > looking at iso (like your iso mentioned) we need at least L2 because we want > to model attributes of properties. > > We had several option for extending OPM-L2 to make the iso based cen > properties work like: > - adding a opm:PropertyDefinition and link to it (Height becoming an instance) > - same and use punning iso relationship (so double rdf:type) > - adding Height as subclass of opm:Property (an assigned and valued property) > and then add constraints (restrictions/shapes); this time having semantics > towards instances... > - and...now it seems doing as previous bullit but now add data type > properties for the class Height iso constraints sacrafying owl-dl > > This last bullit would be quite simple: no need to extend opm, and just > define the cen properties according to conceptual iso spec in a separate > ontology also modelling the "attributes" as meta-properties". > > All thanks very much for your extensive feedback, really appreciated! > > Greetings, Michel > > ps > Tomorrow for some other iso meeting I have the discussions again on modelling > inverse properties or not when there is no need to constrain. Holger already > gave an example avoinding redundant triples. If some of you have som more > ammunition to fight the idea that we should introduce for every > objectproperty an inverse by default....very welcome! (note we are in owl > env. not shacl). > > > > > > > > > If the intent is that a property like Height is a class (e.g. “2 metre” is > the class with members being all things that are of height 2 m), then this is > the same approach as found in ISO 15926 (FWIW based in 4-dimensionalism) and > is indeed far beyond OWL DL. > > One reasonable perspective is that a DL reasoner is just a tool, not a > straightjacket. In situations like this, some people partition the ontologies > into separate OWL DL-compliant graphs and only ever run the reasoner over the > partitions, not the whole. Others move on to using rule-based inference (e.g. > simple RDFS inference then SHACL Rules) rather than using a DL reasoner. You > can also use DL reasoner- and rules-based-inference together if care is > taken (we showed that in the V-Con project). > > Cheers, > David > >> On 27 Feb 2019, at 11:36, Richard Cyganiak <[email protected] >> <mailto:[email protected]>> wrote: >> >> Are you in an environment that prescribes OWL DL? >> >> If not, then stop working with one hand tied behind your back! >> >> If you indeed must stick to OWL DL, I have nothing to offer but my heartfelt >> sympathy! >> >> Richard >> >> >> >>> On 27 Feb 2019, at 09:05, 'Bohms, H.M. (Michel)' via TopBraid Suite Users >>> <[email protected] <mailto:[email protected]>> >>> wrote: >>> >>> Someone proposed the following pattern: >>> >>> ex:Height rdf:type owlClass ; >>> rdfs:subClassOf opm:Property ; >>> prefUnit "m" ; >>> quantityKind cdt:length . >>> >>> Seems turtlewise ok. >>> Seems rdfwise ok. Guess same as rdfwise.... >>> Seems owlwise not ok...giving properties other than annotation properties >>> to a class. >>> Could it be rdfswise ok...in case of change to rdf:type rdfs:Class? >>> >>> Thx for advice! Datawise it would be very welcome/handy just strugling with >>> the interpretation.... >>> >>> Greetings michel >>> >>> >>> >>> >>> >>> >>> Verzonden van mijn Android-telefoon via TouchDown (www.symantec.com >>> <http://www.symantec.com/>) >>> >>> 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] >>> <mailto:[email protected]>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> 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 >> <https://groups.google.com/d/optout>. > > 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]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > -- > 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 > <https://groups.google.com/d/optout>. 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]. For more options, visit https://groups.google.com/d/optout.
