|
DAML ValidatorHome | About DAML | Announcements | Roadmap | Site Search |
The DAML Validator is a tool to check DAML+OIL (March 2001) markup for problems beyond simple syntax errors. The Validator reads in your DAML file and examines it for a variety of potential errors. It then provides you with a listing of errors, a pointer to the error in your file, and some guidance on the nature of the problem.
The DAML Validator is no longer actively supported. Our attention has shifted to the OWL Validator.
New! Aug 20, 2003: The Validator now does some inferencing. It will infer types from superclasses and equivalent classes. It also infers properties from hasValue restrictions.
The Validator is available via either a WWW interface or download.
Choose one: DAML Validator - 2003.08.20
Please note that the readme file contains information that is current for the WWW version and the downloadable validator may be older.
The Validator uses the ARP parser from the Jena toolkit to create an RDF triple model from the page being validated and all pages that it references. A custom node based model is then built on top of this that supports the Validator. From this model the validator checks the DAML markup in the submitted file. It assumes that all referenced markup is correct.
The Excel spreadsheet IndicationList.xls lists the indications generated by the validator along with a description of what causes each indication. There are also a number of example files listed for each indication that demonstrate correct and incorrect markup.
The Readme.txt file contains a list of recent changes plus a "to do" list of bugs to fix and future work.
URIs
During model creation the validator checks for namespace problems (outdated URIs, file extensions in URIs) and reports parse problems generated by the parser. If there is a parse problem with the file being validated, processing stops. The validator uses the ARP parser from the Jena toolkit (1.5.0).
Resources
In this stage the validator tests RDF resources for existence. Any subject,or object resource that is referenced must have a defined type. If there is no type, the validator reports an Undefined Resource Indication. These resources can be defined within the file being validated or in the referenced markup.
Properties that are not explicitly defined are treated as an implicit property with no globally applicable restrictions. The Property is then explicitly defined in the model. Because the validator can not determine if the Property was intentionally implicit or not, an Information Indication is generated. The user should confirm that there are not problems with the property.
Tip: Because DAML is type sensitive, capitalization problems are a large cause of Undefined Resource indications.
Statements
In this stage the Validator checks each statement against the global domain and range constraints of the predicate. The subject and object of a statement should be instances of the predicate's domain and range classes. The validator produces Invalid Domain or Invalid Range Indications for these errors.
Datatypes
The Validator uses an XML Schema datatype validator based on the Oracle XML Developers Toolkit (XDK). In statements where the range of the statement is restricted to a XML Schema datatype, the value is validated against the datatype definition. At this time only SimpleTypes are validated. The validator does not handle ComplexTypes correctly and will produce an indication even if the use is correct.
Any errors in the Oracle XDK will affect the DAML Validator. We know of at least one error dealing with regular expressions: When a charGroup ends with an escaped dash, eg. [a\-].
Nodes
A node is an RDF Resource and it's accompanying statements. A node is classified as being one of the following types: Class, Property, Restriction, ObjectRestriction, DatatypeRestriction, or an Instance of one or more classes. The first five types are actually Instances too, but for the purposes of validation they are treated separately. If a node belongs to multiple types that are incompatable an Indication is generated.
Each node is then validated based on the type. Instance nodes are tested against restrictions on their class types. The validator checks for Cardinality, CardinalityQ, hasClass, hasValue, and toClass violations. See IndicationList.xls for more information.
Output
The Validator generates a list of Indications. Each Indication has a level (Error, Warning, or Information), type (eg. Undefined Resource), message (text string describing the problem), id number, and location. What the location is depends on the type of indication. Parse indications show a chain of namespace or imports references. Undefined Resource indications list all statements that reference the resource, grouped by file. Cardinality and other Restriction indications report the restriction node, instance node, and any statements.
When possible a line number is given with a statement or resource. Due to limitations in the parser the line numbers refer to the closing tag of an element that contains the statement, and the column numbers seem completely useless.
The standalone validator produces output as plain text or as an xml file. The validator DTD is defined in validator.dtd. The web based validator generates HTML from the XML output and uses HyperDAML in some places.
ICS-FORTH and W3C have developed validators for RDF(S).
An adaptation of the DAML Validator to support the OWL Web Ontology Language is available here.
I have made available my Jena 1.6.1 modification that stores locations (source and line number) with each statement.