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 <[email protected]> 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 <[email protected] > > > wrote: > > 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 <[email protected]> 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 > > > > On Tue, Oct 5, 2010 at 9:41 PM, Gokhan Soydan <[email protected] > > >wrote: > > > > > 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 > > > > > On 10/5/2010 6:02 PM, Arthur Keen wrote: > > > > > 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 <[email protected] > > >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. > > > > >> 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 > > > > >> On 10/5/2010 9:32 AM, Arthur Keen wrote: > > > > >> 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 > > ... > > read more » -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en
