from property to constraint

[Bohms, H.M. (Michel)]

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...@tno.nl Location   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.

 

 

[Irene Polikoff]

1. Any reason you are not using QUDT?

2. Any reason you are not using SHACL?

3. I found it strange that you are embedding a unit of measure into a string e.g., “2.40m”.

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.

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.

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 ;

    ] ;

.

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 .

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.

<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-user...@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.

[Bohms, H.M. (Michel)]

Hi Irene,

 

Se after >

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

> 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?

 

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)

 

 

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.

 

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).

 

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)

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8BF7DEBD-276A-4D57-BCD5-A84237F77E27%40topquadrant.com.

[Ralph TQ [Gmail]]

I respond to:

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..

Dereferencing at the graph level is underway.

> Has this situation changed?

QUDT is now very active again - take a look at the latest catalog which can be reached at www.qudt.org 

Al units now have consistent URIs. 

Dimension vectors and dimensionless quantity kinds (for example ratios) have or are about to be published.

Is there now finally some free nasa/tq handbook?

No - NASA are wanting a web-based version of QUDT and that is what is happening.

Copying Steve Ray who is the lead ontology manager for QUDT.

Ralph

On Jul 8, 2019, at 3:53 PM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Hi Irene,

 

Se after >

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@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: topbrai...@googlegroups.com <topbrai...@googlegroups.com> On Behalf Of Irene Polikoff
Sent: zondag 7 juli 2019 17:06
To: topbrai...@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?

 

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)

 

 

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>

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/200f7b244fdd4febb194250385f7892b%40tno.nl.

[Irene Polikoff]

Michel,

Please see below

Sent from my iPhone

On Jul 8, 2019, at 3:53 PM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Hi Irene,

 

Se after >

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@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: topbrai...@googlegroups.com <topbrai...@googlegroups.com> On Behalf Of Irene Polikoff

Sent: zondag 7 juli 2019 17:06
To: topbrai...@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.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/200f7b244fdd4febb194250385f7892b%40tno.nl.

[dprice]

On 8 Jul 2019, at 20:53, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

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)

 

The WKT is not really very similar to doing a special encoding of UoM inside a datatype. One is encoding lists of lists, arrays, etc. (which RDF cannot handle or cannot handle very nicely) of numerical values as strings, and the other is simply taking shortcuts with the modelling. As QUDT and other similar UoM ontologies show, it is not difficult to model and encode values with a UoM in normal RDF that require no specialised tools. Using an odd datatype encoding extension means that only specialised tools that understand that encoding can do any calculations, comparisons, etc. over those values. If the UoM is modelled in a normal way, then all RDF tools (e.g. vanilla SPARQL endpoints) can be used out-of-the-box to do calculations, comparisons, etc.

Cheers,

David

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

 

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...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/A57627E3-C44F-46E6-81EF-54C607F6EE1D%40topquadrant.com.

[Bohms, H.M. (Michel)]

Agreed.

 

WKT strings in general need extra agreements on the string structure ie how to parse.

 

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location   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: topbrai...@googlegroups.com <topbrai...@googlegroups.com> On Behalf Of dprice
Sent: dinsdag 9 juli 2019 00:26
To: topbrai...@googlegroups.com
Subject: Re: [topbraid-users] from property to constraint

 

 

--

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-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/CA00F884-FF8F-4075-AD2D-945030D7BA6E%40topquadrant.com.

[Bohms, H.M. (Michel)]

Thx for the update Ralph, see after >

 

 

“Dereferencing at the graph level is underway.”

 

> That is exactly the feedback for years now. Do you have some point in time?

 

 

QUDT is now very active again - take a look at the latest catalog which can be reached at www.qudt.org 

 

> This site takes extremely long to load (Chrome, IE) and sometimes there is no result at all for me.

 

 

Al units now have consistent URIs. 

 

Dimension vectors and dimensionless quantity kinds (for example ratios) have or are about to be published.

Is there now finally some free nasa/tq handbook?

 

No - NASA are wanting a web-based version of QUDT and that is what is happening.

 

> ok, that’s better indeed!

 

Copying Steve Ray who is the lead ontology manager for QUDT.

 

> Thx Michel

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/D88671C3-18B9-4061-98FF-35BCEF2021D5%40topquadrant.com.

[Irene Polikoff]

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 <topbrai...@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...@tno.nl Location

<image001.gif>

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/0673c36affd14e49a766c4c6524a6ba7%40tno.nl.

[Bohms, H.M. (Michel)]

In option one there is only a datatype property height for which it is hard to specify meta data like quantitykind.
So the quantitykind as a datatype by opm is a way to deal with that in the data
Not ideal but a way...

Verzonden van mijn Android-telefoon via TouchDown (www.symantec.com)

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/4ECF2630-274E-4D61-8FF8-A11ABEBBBEB9%40topquadrant.com.

[Bohms, H.M. (Michel)]

Hi Irene

Coming back to modelling with constraints.

 

 

I can only say “OK” when I used quotes.

With no quotes I get:

Where:

 

bs:hasQuantity

  rdf:type owl:DatatypeProperty ;

  rdfs:range rdfs:Datatype ;

  skos:prefLabel "has quantity"@en ;

  skos:prefLabel "heeft grootheid"@nl ;

.

 

and

“

cdt:length

  rdf:type rdfs:Datatype ;

  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 ;

  rdfs:label "length"@en ;

  rdfs:subClassOf rdfs:Resource ;

.

Thanks again for advice what I am doing wrong...Michel

 

Ps

Or....should I use AllValuesFrom in this constraintform?

So that I get:

 

ex2:Height

  rdf:type owl:Class ;

  rdfs:subClassOf owl:Thing ;

  rdfs:subClassOf [

      rdf:type owl:Restriction ;

      owl:allValuesFrom cdt:length ;

      owl:onProperty bs:hasQuantity ;

    ] ;

.

And

ex2:ClearOpeningHeight

  rdf:type owl:Class ;

  rdfs:subClassOf ex2:Height ;

  rdfs:subClassOf [

      rdf:type owl:Restriction ;

      owl:hasValue "EN12519" ;

      owl:onProperty rdfs:seeAlso ;

    ] ;

.

 

The more I think...I think this is what I did wrong 😊

 

 

 

 

Dr. ir. H.M. (Michel) Böhms Senior Data Scientist T +31888663107 M +31630381220 E michel...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/4ECF2630-274E-4D61-8FF8-A11ABEBBBEB9%40topquadrant.com.

[Irene Polikoff]

I never use this dialog. I simply type in Manchester syntax.

But I see that you are using a datatype property. In this case, it ic correct that the value should be a literal.

On Jul 10, 2019, at 9:13 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Hi Irene

Coming back to modelling with constraints.

 

<image002.jpg>

 

I can only say “OK” when I used quotes.

With no quotes I get:

<image004.jpg>

<image005.gif>

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/588b22a6103e4c11acef53fdec97604d%40tno.nl.

[Bohms, H.M. (Michel)]

 

I never use this dialog. I simply type in Manchester syntax.

 

But I see that you are using a datatype property. In this case, it ic correct that the value should be a literal.

 

> right but because I here want to constrain all values being of a certain range (ie cdt:length) I guess I have to use allvaluesfrom iso hasValue (that waytbc is fine without the quotes....)

 

Right?

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/B47E2AB9-D2B3-4014-9C01-D896C78A2BB5%40topquadrant.com.

[Irene Polikoff]

Michel,

Since you are not using the property in the restriction to store any values, there is no way this restriction would restrict the values. 

You are placing the restriction on  bs:hasQuantity and you are using to store values bs:hasValueUnit.

ex:Height_1 rdf:type ex:Height ;

                bs:hasValueUnit “2.40 m”^^cdt:length .

What a hasValue restriction on bs:hasQuantity would do (provided you have the software that does it) is add an inferred triple:

ex:Height_1 rdf:type ex:Height ;

                bs:hasValueUnit “2.40 m”^^cdt:length ;

bs:hasQuantity cdt:length.

bs:hasQuantity would have to be an object property.

All values from restriction would do nothing UNLESS in your data you will explicitly use bs:hasQuantity property. If you do:

ex:Height_1 rdf:type ex:Height ;

                bs:hasValueUnit “2.40 m”^^cdt:length ;

bs:hasQuantity cdt:length.

Then, bs:hasQuantity would have to be an object property.

If you do

ex:Height_1 rdf:type ex:Height ;

                bs:hasQuantity “2.40 m”^^cdt:length.

bs:hasQuantity would have to be datatype property.

At a risk of repeating myself, none of the class definition options you are proposing make sense in the combination with the use of cdt:length in {bs:hasValueUnit “2.40 m”^^cdt:length}.

I will leave the topic at this since we have resolved your TBC issue and this is primarily a product support forum. 

The rest of the discussion is about general modeling approaches and the use of modeling languages. Unfortunately, I can’t provide any additional guidance. If other people on the forum are interested in this, feel free to continue the discussion.

Regards,

Irene

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/d8043c4484fe462da22b39db6f88dd2f%40tno.nl.

[Bohms, H.M. (Michel)]

 

Michel,

 

Since you are not using the property in the restriction to store any values, there is no way this restriction would restrict the values. 

 

> not directly no (I am not restricting values via hasValue) but I would say indirectly yes (via meta).

> In OWL Full I would specify for the Height class: :hasQuantityKind cdt:length (a value of meta-datatype “rdfs:Datatype”)

> wanting to stay OWL DL and model the same as restriction I would get:

 

> AllValuesFrom cdt:length for the hasValue property....I think this is consistent....

 

> so indirectly I am restricting the value for hasValue by restricting its range to be cdt:length (and not just any rfds:Datatype...)

 

> note I changed to the term quantityKind to not confuse it with an actual value....

 

> all below I can see if you would all be on the same metalevel....however here we are on two metalevels...and then its IMHO ok again....

 

> please reconsider....

> it is exactly related with the issue I had earlier with the quotes when doing a hasValue constraint...I wanted without quotes (meta) but then I needed an allvaluesfrom constraint...)

 

> I added the full example as annex (having one metaconstraint, the quantitykind and one normal constraint now with hasValue, all doing fine now in tbc....

 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/86E9E94B-6975-4C25-91A5-8C3BED4A3660%40topquadrant.com.

[Irene Polikoff]

If you are using hasValue restriction on a datatype property, then the value in the restriction must be a literal. Nothing else would make sense - irrespective of the species of OWL. If you want to use a resource in this restriction, then it should be an object property. This would also be true if you were using one of the built-in types as a value e.g., xsd:string in owl:hasValue restrictionbecause this restriction says that the value of the property = xsd:string, not that the type of the value is xsd:string.

If you were to use allValuesFrom, then would be saying that the type of values must meet the constraint, so in this case, you can set the restriction to your new datatype even if the restricted property was a datatype property.

I read your explanations and I continue to find the modeling approach you are describing confusing and obscure. 

You are not using the standard according to its entailed semantics or the typical practices. The meaning of OWL statements are defined by the inferences they produce. Anyone who would try to interpret your model using normal expectation would come to the wrong assumptions about what it is trying to say and how to use it. Whether in the end, what you produces passes the criteria of being in DL or not, it is irrelevant. It would largely depend on the data. If you use allValuesFrom, but never have any actual values for bs:quantityKind, then there isn’t anything for the validation to be concerned about. 

In the end, it is all RDF and one can say anything they want in RDF. You could decide to treat OWL simply as a vocabulary that gives you some language elements that you are using in a way you decide, not following any standard semantics. However, my advise would be to not do this. If, for whatever reason, the standard use does not work for you, I would advise to create your own language and not use OWL namespace. You could define your own my:hasValue and use it to mean anything you want. Then, everyone would be clear that they should not assume OWL semantic, but need to read and follow the definitions you supply for this property.

[Bohms, H.M. (Michel)]

Ok thx

Think my mistake is that i should use the hasValue in the restriction....
The has quant.kind would only work when using say qudt:length i guess or some other non datatype way.

Verzonden van mijn Android-telefoon via TouchDown (www.symantec.com)

-----Original Message-----
From: Irene Polikoff [ir...@topquadrant.com]

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/86E9E94B-6975-4C25-91A5-8C3BED4A3660%40topquadrant.com.

[Bohms, H.M. (Michel)]

Dear Irene
I agree part of obscurity comes from cdt datatype approach for quantitykinds...
If only we had some simple resources from qudt2....a length.....a meter.
Length seems still not there.

Then i could use a hasvalue restriction on qudt:quantitykind being a length for my Height subclass of Property....

Assuming i could then infer for all instances of Height that the quantity kind was length
Right?

Verzonden van mijn Android-telefoon via TouchDown (www.symantec.com)

-----Original Message-----
From: Irene Polikoff [ir...@topquadrant.com]

Received: woensdag, 10 jul. 2019, 18:07
To: topbrai...@googlegroups.com [topbrai...@googlegroups.com]
Subject: Re: [topbraid-users] from property to constraint

--
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-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/2B0CD85D-19B6-476A-AB8C-E736060D5D92%40topquadrant.com.

For more options, visit https://groups.google.com/d/optout.

 

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.