Value constraint on property using qudt unit type throws exception

[Arthur Keen]

I am using TBCME 3.3.2 on Mac OS-X 10.6.4 and QUDT delivered with Topbraid

I would like to add value constraints on properties using qudt unit types.

For example, on owl:DatatypeProperty casingTemperature with rdfs:range unit:DegreeFahrenheit

I would like to specify that the temperature range greater than zero, so I tried to create a range constraint (a) and then a local restriction (b) on the class for casingTemperature.

In both cases, TBCME parses the input field on input and toggles the input text from red to black text at the last ']' as expected, however when I click 'OK', TBCME throws an exception.

a) unit:DegreeFahrenheit[>0] on the property range, and

b) casingTemperature only unit:DegreeFahrenheit[>0]

Is this a bug?

This seemed like a reasonable approach, but given the exception, should I rather express the constraints using xsd:Double[>0]?  The icon on unit:DegreeFahrenheit has a "D" on it, so is it an extension of an xsd:Double?

Regards

Arthur

The Exception:

java.lang.reflect.InvocationTargetException

at org.topbraid.core.change.AbstractChangeEngine.execute(AbstractChangeEngine.java:282)

at org.topbraidcomposer.core.change.TBCChangeEngine.execute(TBCChangeEngine.java:172)

at org.topbraidcomposer.core.change.TBCChangeEngine$1.run(TBCChangeEngine.java:142)

at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

Caused by: org.eclipse.core.commands.ExecutionException: While executing the operation, an exception occurred

at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:519)

at org.topbraid.core.change.AbstractChangeEngine.execute(AbstractChangeEngine.java:268)

... 3 more

Caused by: java.lang.IllegalStateException: we failed to create the object: org.topbraid.owl.man.parser.ParseException: Encountered ".

Was expecting one of:

at org.topbraidcomposer.change.lib.ReplaceObjectChange.execute(ReplaceObjectChange.java:53)

at org.topbraid.core.change.ChangeOperation.execute(ChangeOperation.java:105)

at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:511)

... 4 more

Caused by: org.topbraid.owl.man.parser.ParseException: Encountered ".

Was expecting one of:

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.generateParseException(ManchesterSyntaxParser.java:1416)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLDataRangeFacet(ManchesterSyntaxParser.java:882)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLDataRangeRestriction(ManchesterSyntaxParser.java:836)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLDataRange(ManchesterSyntaxParser.java:792)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLRestrictionOrNamedClass(ManchesterSyntaxParser.java:312)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLComplementClass(ManchesterSyntaxParser.java:291)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLIntersectionClass(ManchesterSyntaxParser.java:242)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLXORClass(ManchesterSyntaxParser.java:209)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLUnionClass(ManchesterSyntaxParser.java:176)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.parseFile(ManchesterSyntaxParser.java:167)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.parseClass(ManchesterSyntaxParser.java:149)

at org.topbraid.change.ClassObjectProvider.getObject(ClassObjectProvider.java:29)

at org.topbraidcomposer.widgets.row.editors.ClassEditorText$1.getObject(ClassEditorText.java:99)

at org.topbraidcomposer.change.lib.AbstractReplaceObjectChange.replaceObject(AbstractReplaceObjectChange.java:113)

at org.topbraidcomposer.change.lib.ReplaceObjectChange.execute(ReplaceObjectChange.java:49)

... 6 more

Root exception:

org.eclipse.core.commands.ExecutionException: While executing the operation, an exception occurred

at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:519)

at org.topbraid.core.change.AbstractChangeEngine.execute(AbstractChangeEngine.java:268)

at org.topbraidcomposer.core.change.TBCChangeEngine.execute(TBCChangeEngine.java:172)

at org.topbraidcomposer.core.change.TBCChangeEngine$1.run(TBCChangeEngine.java:142)

at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)

Caused by: java.lang.IllegalStateException: we failed to create the object: org.topbraid.owl.man.parser.ParseException: Encountered ".

Was expecting one of:

at org.topbraidcomposer.change.lib.ReplaceObjectChange.execute(ReplaceObjectChange.java:53)

at org.topbraid.core.change.ChangeOperation.execute(ChangeOperation.java:105)

at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:511)

... 4 more

Caused by: org.topbraid.owl.man.parser.ParseException: Encountered ".

Was expecting one of:

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.generateParseException(ManchesterSyntaxParser.java:1416)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLDataRangeFacet(ManchesterSyntaxParser.java:882)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLDataRangeRestriction(ManchesterSyntaxParser.java:836)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLDataRange(ManchesterSyntaxParser.java:792)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLRestrictionOrNamedClass(ManchesterSyntaxParser.java:312)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLComplementClass(ManchesterSyntaxParser.java:291)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLIntersectionClass(ManchesterSyntaxParser.java:242)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLXORClass(ManchesterSyntaxParser.java:209)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.OWLUnionClass(ManchesterSyntaxParser.java:176)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.parseFile(ManchesterSyntaxParser.java:167)

at org.topbraid.owl.man.parser.ManchesterSyntaxParser.parseClass(ManchesterSyntaxParser.java:149)

at org.topbraid.change.ClassObjectProvider.getObject(ClassObjectProvider.java:29)

at org.topbraidcomposer.widgets.row.editors.ClassEditorText$1.getObject(ClassEditorText.java:99)

at org.topbraidcomposer.change.lib.AbstractReplaceObjectChange.replaceObject(AbstractReplaceObjectChange.java:113)

at org.topbraidcomposer.change.lib.ReplaceObjectChange.execute(ReplaceObjectChange.java:49)

... 6 more

[Gokhan Soydan]

Hi Arthur,

In your example, unit:DegreeFahrenheit is tried to be used as a datatype, whereas it is actually an instance. TBC uses a Manchester Syntax parser, for Manchaster-Syntax style "visualizations" like OWL 2 user-defined datatypes. In your example, this produced an exception, most probably because the instance is tried to be used as a datatype. (Actually, the exception is too cryptic to catch this, so we will try to produce a more user-friendly exception in a later release)

I attached a small ontology with examples of OWL 2 user-defined datatypes in ranges and restrictions. Please display system classes and system properties from Preferences to be able to see some of the example resources in the Classes and Properties views.

The OWL 2 user-defined (advanced) datatypes are also described here.
http://www.w3.org/TR/owl2-primer/#Advanced_Use_of_Datatypes

To choose a syntax for easier reading of the examples, please look at the following link:
http://www.w3.org/TR/owl2-primer/#OWL_Syntaxes

As far as I have seen, QUDT doesn't contain OWL 2 user-defined datatypes, so please create your own like the one's I did or like the one's from the link.

Gokhan

--
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include TopBraid Composer,
TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN.
To post to this group, send email to
topbrai...@googlegroups.com
To unsubscribe from this group, send email to
topbraid-user...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/topbraid-users?hl=en

[Arthur Keen]

Gokhan,

Thanks for the example.  I was able to leverage it to get the qudt units to work in owl value constraints and an earlier email from Holger to get the units to work as types.

From Holger: Add a triple to make qudt:Unit rdfs:subClassOf rdfs:Datatype. Then I could set the range of a datatype property to Centimeters, and the form allows me to enter the literal with Centimeter as datatype.

  - This works great as assigning values to properties that have unit types assigned,  results the correct literal type being assigned, e.g., 98.6^^unit:DegreeFahrenheit

  - However this solution did not work for value constraints as described in this email.

I noticed in your example that you had subclasOf xsd:double and I had been concerned about the numeric type of the unit:units, because I could not find an explicit reference to xsd:double in the model, so I added a statement to subclassOf xsd:double to unit:Fahrenheit and tried unit:Fahrenheit[>90, <110], and it works.  I think it will still work if I remove the <qudt:Unit rdfs:subClassOf rdfs:Datatype> suggested by Holger

On Tue, Oct 5, 2010 at 6:28 PM, Gokhan Soydan <gso...@topquadrant.com> wrote:

Hi Arthur: Hi Arthur,

I have added a triple to make qudt:Unit rdfs:subClassOf rdfs:Datatype. Then I could set the range of a datatype property to Centimeters, and the form allows me to enter the literal with Centimeter as datatype.

[Gokhan Soydan]

Arthur,

>  I think it will still work if I remove the <

qudt:Unit rdfs:subClassOf rdfs:Datatype> suggested by Holger

The rdfs:subClassOf triple is used there to indicate that qudt:Unit is also an rdfs:Datatype, so any instances of qudt:Unit are datatypes. So, you may need to keep that triple. However, semantically, there seems to be a problem with that subClassOf relationship, because qudt:Unit is at the class level, whereas rdfs:Datatype is at the metaclass level. So, for creating proper datatypes, I would rather suggest using OWL 2 primer in the following link as a starting point.

http://www.w3.org/TR/owl2-primer/#Advanced_Use_of_Datatypes

If your solution already satisfies your needs, then you wouldn't need to follow the above link.

I was told that we are working also on a newer version of QUDT with user-defined datatypes, but it won't be released yet due to some issues.

Gokhan

[Arthur Keen]

Gokhan

Thanks very much for the help.   It is great to be able to specify axioms like:

gasRate only myunit:MCSF[>=0], 

internalDiameter only unit:Inch[>= 1.0 , <= 10.0], and 

outerDiameter only unit:Inch[>= 2.0 , <= 10.0]

And I also look forward to using the newer QUDT when it is ready.

I do need to deal with constraint coupling between properties like internalDiameter<externalDiameter, and it does not look like that is doable using OWL axioms, so I will use SPIN for that.

Arthur

[Scott Henninger]

Arthur; It is the case that OWL covers a rather small area of the
solution space. Rules, in the form of SPARQL, etc. then become
necessary. So SPARQL Rules (SPIN) is a good choice. Note that rules
for OWL 2 RL profile are included in the TBC library. For more, see
http://www.topquadrant.com/products/TBS_FAQ.html#TBC11

An advantage of using the OWL 2 rules in SPARQL Rules is that both OWL
and your rules are in the same representation - SPARQL.

-- Scott

On Oct 6, 9:53 am, Arthur Keen <arthur.a.k...@gmail.com> wrote:
> Gokhan
>
> Thanks very much for the help.   It is great to be able to specify axioms
> like:

> gasRate *only *myunit:MCSF[>=0],
>
> internalDiameter *only* unit:Inch[>= 1.0 , <= 10.0], and
>
> outerDiameter *only* unit:Inch[>= 2.0 , <= 10.0]

>
> And I also look forward to using the newer QUDT when it is ready.
>
> I do need to deal with constraint coupling between properties like
> internalDiameter<externalDiameter, and it does not look like that is doable
> using OWL axioms, so I will use SPIN for that.
>
> Arthur
>

> >>  *The Exception:*

> ...
>
> read more »

[Arthur Keen]

Thanks for the tip. The advantages are very clear.  Another thing I really like about this:  If you need a clear understanding of an owl 2 construct - simply look up the SPARQL SPIN rules that implement it, the SPARQL is very succinct and easy to understand.  

[Scott Henninger]

Arthur; Yes, this does take the mystery out of OWL (this is a direct
quote from someone in the TBS Advanced Product Training last week).
Note that the OWL 2 RL rules are a direct implementation of the
standard, found at http://www.w3.org/TR/2009/WD-owl2-profiles-20090421/#Reasoning_in_OWL_2_RL_and_RDF_Graphs_using_Rules.

The SPARQL rules to implement OWL 2 RL are also found in a Web page
at: http://topbraid.org/spin/owlrl-all.html

There is also an RDFS+ implementation (a little bit of semantics goes
a long ways) at http://topbraid.org/spin/rdfsplus.html.

The rule set for RDFS and RDFS+ are included in the TopBraid library
in TopBraid/SPIN/{spinrdfs.rdf, rdfsplus.rdf}. The TDFS+
implementation is new for TBS 3.3.3.

-- Scott

On Oct 6, 7:11 pm, Arthur Keen <arthur.a.k...@gmail.com> wrote:
> Thanks for the tip. The advantages are very clear.  Another thing I really
> like about this:  If you need a clear understanding of an owl 2 construct -
> simply look up the SPARQL SPIN rules that implement it, the SPARQL is very
> succinct and easy to understand.
>

> On Wed, Oct 6, 2010 at 11:49 AM, Scott Henninger <shennin...@topquadrant.com

> ...
>
> read more »