I don’t believe that storing quantity kind with the measurements is required in any of the 3 options.
With every option, including option 1, you are defining a resource :Height that is used when capturing measurements. And with every option, quantity kind is already associated with the :Height. Sent from my iPhone > On Jul 9, 2019, at 3:26 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users > <topbraid-users@googlegroups.com> wrote: > > > Wrt “strings to things” > > > fully agree, so the “quantityKind as datatype” is only relevant in the > > case that the quantity is modelled the simplest wat (OPM L1) that is “as > > owl:DatatypeProperty”. (other then going beyond DL putting the quantityKind > > at the property declaration. > > Ps > Over Summer I will write a note for W3C LBD CG on “Property Modelling” > involving all options with pros and cons. Including > - extra-logical annotation > - reification > - singleton properties > - use of datatype for unit or quantityKind > - use of WKT strings > - misuse of named graphs (one triple per graph) > - extra-logical serialisation (quads) > - objectification > - RDF* potential > - all with or without DL > > All based on the need to define meta-data (at least things like unit and > quantityKind but typically more) for properties. Sometimes at the > predicate/triple-level sometimes at the definition. > > > > > > > > > Dr. ir. H.M. (Michel) Böhms > Senior Data Scientist > > T +31888663107 > M +31630381220 > E michel.bo...@tno.nl > Location > > > <image001.gif> > 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: topbraid-users@googlegroups.com <topbraid-users@googlegroups.com> On > Behalf Of Irene Polikoff > Sent: dinsdag 9 juli 2019 00:03 > To: topbraid-users@googlegroups.com > Subject: Re: [topbraid-users] from property to constraint > > > Michel, > > Please see below > > Sent from my iPhone > > On Jul 8, 2019, at 3:53 PM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users > <topbraid-users@googlegroups.com> wrote: > > Hi Irene, > > Se after > > > > Dr. ir. H.M. (Michel) Böhms > Senior Data Scientist > > > T +31888663107 > M +31630381220 > E michel.bo...@tno.nl > Location > > > <image001.gif> > 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: topbraid-users@googlegroups.com <topbraid-users@googlegroups.com> On > Behalf Of Irene Polikoff > Sent: zondag 7 juli 2019 17:06 > To: topbraid-users@googlegroups.com > Subject: Re: [topbraid-users] from property to constraint > > 1. Any reason you are not using QUDT? > > > I used to be a fan of qudt2.0 but after many years of unknown status/no > > dereferenceable specs I looked around... > > Has this situation changed? Is there now finally some free nasa/tq handbook? > > Hmm... QUDT is a community effort, not owned by either NASA or TQ although > it’s initial development was funded by NASA. > It is already pretty mature and things like a handbook, etc., are all > possible if people are interested in having this and are willing to > contribute - just as it is with any other open source, community efforts. > So, it becomes a choice to make for people interested in this domain - > support QUDT through some contribution or start anew their own effort and > repeat the work. > > 2. Any reason you are not using SHACL? > > >parties we work with are using rdfs/owl, well could be shacl-variant also. > > 3. I found it strange that you are embedding a unit of measure into a string > e.g., “2.40m”. > > > well when the datatype is taken by the quantitykind...this is the only > > place left when using simple datatype properties........ > > its not that strange, often used for GIS like coordinates etc. (general: > > WKT-WellKnownText strings). > > https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometry > > (ex) > > My point was that you do not need to specify a quantity kind for a specific > measurement because you have already specified it for a class (options 2 and > 3) or for the type instance (option 1). > > If you will be specifying it for each measurement, then what is the point to > provided with the definition of the Height? > > Further, I believe that one of the main goals of RDF standards is to move > from “strings to things” - explicit semantics not embedded in strings. > > > > 4. Option one is simpler than option two for defining Height. It requires an > extra triple when using Height. This does not seem “too much” to me fo use in > systems since querying restrictions is more complex than just using a simple > triple. > > > guess you are right..just people do not like the XType classes (which done > > really well should involve punning I think: 2 times rdf:type iso a hasType > > attribute). > > Given OWL reasoner, option 2 entails some inferences. Option 1 does not > entail any inferences, but “given OWL reasoner” is an assumption that is > typically not practical since there are very few OWL reasoners available and > next to none in use. You could implement a rule that defines your own > inference for option 1. > > 5. Not sure what problems you have with using cdt:length in the restriction. > I can’t reproduce the issue, it works for me - see below. > > In my example, I did not give example:hasQuantity any range, it does not > matter whether you specify range or not. > > <image003.png> > And in RDF > > example:Height > rdf:type owl:Class ; > rdfs:subClassOf example:Property ; > rdfs:subClassOf [ > rdf:type owl:Restriction ; > owl:hasValue example:length ; > owl:onProperty example:hasQuantity ; > ] ; > . > > Guess my issue is related with the definition of cdt:length: > (if I do not include quotes tbc will not accept the input) > Cdt”length is defined as: > > “ > cdt:length a rdfs:Datatype ; > rdfs:label "length"@en ; > rdfs:comment """Datatype to encode measurement of quantity kind length in > a simple literal. > > Lexical space is the concatenation of the lexical form of an xsd:decimal, > optionally followed by 'e' or 'E' and the lexical form of an xsd:integer, at > least one space, and a length unit chosen in the Unified Code for Units of > Measure code system. > > Value space is the set of length as defined by the International Systems of > Quantities. > > Lexical-to-value mapping maps lexical forms with a length unit to their > corresponding length measures according to the International Systems of > Quantities."""@en . > “ > So its an instance of a rdfs:Datatype to make it usable as datatype (bit like > the unit in qudt). > > I can’t recreate your problem. I did not use quotes and it worked fine for > me. > I also created example:length as a new rdfs:Datatype. > > > Gr M > > > > > 6. As for semantics of this definition, it means that if there is :R1 a > example:Height, then it will be inferred that :R1 example:hasQuantity > example:length. Thus, I do not think it makes sense using length as you are > doing in: > > ex:Height_1 rdf:type ex:Height ; > bs:hasValueUnit “2.40 m”^^cdt:length . > > I do not think it would make sense with the first option either since you are > putting this info on the class itself (option 2 and 3) or into an instance > resource representing Height (option 1). Whether you are using inferences or > not, you can always get this information > > May be you meant to do something like: > > ex:Height_1 rdf:type ex:Height ; > bs:hasValueUnit “2.40”^^cdt:meter . > > > no, this is the qudt way, but my one is the CDT/UCUM way: putting the > > quantity(kind) in the datatype and the unit in the string. Note that > > quantitykind info is much more essential than the unit that is just a scale > > factor. > > 7. Yes, if you don’t have to be in OWL-DL, you can also use option 3. As > option 1, it does not entail any inferences. > > > all clear. Remember now you told me earlier...sorry..anyway, so this could > > be an alternative iso restrictions (going beyond owl-dl) > > > > On Jul 7, 2019, at 7:15 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users > <topbraid-users@googlegroups.com> wrote: > > In the W3C LBD we are comparing different ways of modelling (complex) > properties. > > One option: > > ex:Height rdf:type bs:PropertyType ; > bs:hasQuantity cdt:length . > ex:Door_1 rdf:type ex :Door ; > bs:hasProperty ex:Height_1 . > ex:Height_1 rdf:type bs:Property ; > bs:hasPropertyType ex:Height ; > bs:hasValueUnit “2.40 m”^^cdt:length . > > > but some people think the XType modelling is too much. So they like to just > specialise bs:Property into ex:Height resulting in: > > ex:Height rdfs:subClassOf bs:Property ; > rdfs:subClassOf [ rdf:type owl:Restriction ; > owl:hasValue “cdt:length” ; > owl:onProperty bs:hasQuantity ; ] . > ex:Door_1 rdf:type ex :Door ; > bs:hasProperty ex:Height_1 . > ex:Height_1 rdf:type ex:Height ; > bs:hasValueUnit “2.40 m”^^cdt:length . > > > so the original: > bs:hasQuantity cdt:length . > > becomes a restriction in the second option. > > BUT...as can be seen instead of just > cdt:length > > I have to specify > “cdt:length” with quotes (just cdt:length does not work in > tbc) > > (the range of hasQuantity is rdfs:Datatype) > > In the constraint. > > Is this actually doing what I intended? > > Thx Michel > > Ps related to my earlier OWL Full question, guess an OWL Full option could > also be: > > ex:Height rdfs:subClassOf bs:Property ; > owl:hasQuantity cdt:length . > > > > > > > > Dr. ir. H.M. (Michel) Böhms > Senior Data Scientist > > > > T +31888663107 > M +31630381220 > E michel.bo...@tno.nl > Location > > > <image001.gif> > 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 topbraid-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/2f1adc9bf0894158857783a8220a7165%40tno.nl. > For more options, visit 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 topbraid-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/8BF7DEBD-276A-4D57-BCD5-A84237F77E27%40topquadrant.com. > For more options, visit 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 topbraid-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/200f7b244fdd4febb194250385f7892b%40tno.nl. > For more options, visit 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 topbraid-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/A57627E3-C44F-46E6-81EF-54C607F6EE1D%40topquadrant.com. > For more options, visit 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 topbraid-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/0673c36affd14e49a766c4c6524a6ba7%40tno.nl. > For more options, visit 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 topbraid-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/4ECF2630-274E-4D61-8FF8-A11ABEBBBEB9%40topquadrant.com. For more options, visit https://groups.google.com/d/optout.
