Data Validator Tool: Validating Dataset Content Based On Ontology Descriptions

Introduction
The Data Validator Tool (DVT) is a command line tool that is used to validate data records indexed in OSF datasets according to the description of loaded ontologies. Depending on how the ontologies are described, the DVT will validate the content of the datasets and report possible issues. The DVT is a post-indexation validation mechanism. It doesn't enforce any data validation at indexation time. It does report validation issues when the DVT is run against OSF. Once validation errors are detected, different mechanisms have to be put in place to fix these issues.

This document explains how the DVT should be used. It also explains how the current data validation tests works and how the reported errors should be interpreted. It also explains how the ontologies should be described, using the Protégé ontology editor, to better specify the ontologies in order to take full advantage of the DVT validation tests.

Installation & Configuration
All the installation & configuration steps are directly available on the Data Validator Tool page.

Command Line
Using the DVT command line tool is pretty easy. Its command line options and parameters are:

Usage: dvt [OPTIONS] Usage examples: Validate data: dvt -v Options: --output-xml="[PATH]"                Output the validation reports in a file specified by the path in XML format. --output-json="[PATH]"               Output the validation reports in a file specified by the path in JSON format. --allocated-memory="M"               Specifies the number of Mb of memory allocated to the DVT The number of Mb should be specified in this parameter -v                                   Run all the data validation tests -s                                   Silent. Do not output anything to the shell. -f, --fix                            Tries to automatically fix a validation test that fails Note: not all checks support this option -h, --help                           Show this help section

Let's take a deeper look into each of these parameters. Note that any parameter can be used with any other parameter. Here are a few command line examples for using the DVT:
 * 1) * If you specify this parameter, then you will start the validation process. If you don't specify it, then no validation will be performed by the DVT
 * 2) * If you specify this parameter, then nothing will be outputted to the shell terminal. This is usually used when an external tool performed automated validation using the DVT
 * 3) * If you specify this parameter, then you are asking each of the validation test to try to automatically fix the tests that failed. This option is not supported by all validation checks, so only the ones that support that option will try to fix the validation issues.
 * 4) * If you specify this parameter, then this help will be output to the shell terminal
 * 5) * If you specify this parameter, then all the tests, warnings and errors will be written into a XML file, as specified by the  value. Make sure that the user that runs the DVT do have write permission on the specified  . This is normally used to log validation tests
 * 6) * If you specify this parameter, then all the tests, warnings and errors will be written into a JSON file, as specified by the  value. Make sure that the user that runs the DVT do have write permission on the specified  . This is normally used to log validation tests
 * 7) * If you specify this parameter, then the amount of memory specified will be used by the DVT to run the tests. Depending on the size of the datasets and the tests defined within the ontologies, more memory may be required by the DVT to work normally
 * 1) * If you specify this parameter, then this help will be output to the shell terminal
 * 2) * If you specify this parameter, then all the tests, warnings and errors will be written into a XML file, as specified by the  value. Make sure that the user that runs the DVT do have write permission on the specified  . This is normally used to log validation tests
 * 3) * If you specify this parameter, then all the tests, warnings and errors will be written into a JSON file, as specified by the  value. Make sure that the user that runs the DVT do have write permission on the specified  . This is normally used to log validation tests
 * 4) * If you specify this parameter, then the amount of memory specified will be used by the DVT to run the tests. Depending on the size of the datasets and the tests defined within the ontologies, more memory may be required by the DVT to work normally
 * 1) * If you specify this parameter, then all the tests, warnings and errors will be written into a JSON file, as specified by the  value. Make sure that the user that runs the DVT do have write permission on the specified  . This is normally used to log validation tests
 * 2) * If you specify this parameter, then the amount of memory specified will be used by the DVT to run the tests. Depending on the size of the datasets and the tests defined within the ontologies, more memory may be required by the DVT to work normally
 * 1) * If you specify this parameter, then the amount of memory specified will be used by the DVT to run the tests. Depending on the size of the datasets and the tests defined within the ontologies, more memory may be required by the DVT to work normally

Automatic Validation Error Fixing
Some of the validation check procedure does support the automatic error fixing command line option. If the check does support that option, then it will run an internal procedure to try to fix the validation error itself. Be careful to read the " " section for each of the test to see how the validation errors get fixed.

When a validation error get fixed, it means that the description of the record that failed the validation test will get modified such that the test doesn't fails again. All the automatic validation errors fixing procedures uses the  web service endpoint, and does specify that a revision need to be created for that updated record. What that means is that all the records that get modified by one of the validation procedure will get revisioned, which means that all the fix changes can be roll-backed using the  web service endpoint.

Finally, all fixes are recorded into the log file if the  or the   command line options have been specified for the DVT command.

=Data Validation Tests=

Overview
The DVT includes a series of data validation tests that can be used to test the completeness and consistency of instance records indexed in OSF. If a test fails for a given record, then the error will be reported, explained and logged depending of the DVT parameters that have been specified. These validation tests cover the most common data validation usecases. A test can be used in different ways to validate different things within the dataset. Each of these ways to define a test is explained below within each test description.

In this section, the tests are introduced. Then, a description of the way the test works is provided. If some more technical background is required, then a specific section calling this out follows. A section also explains the different ways you can define ontologies and the impacts on that test. Finally an explanation of how the reported errors and warnings should be interpreted is provided.

Introduction
The  test is used to if the referenced URIs exist within OSF or not. If a record references an undeclared record (because of a missing URI), then an error will be reported.

How it Works
This test gets the list of all records that are referenced by other records but that are not (currently?) defined into OSF. For each of these undefined records, an error will be returned.

It checks for all the values of all the triples at the exception of the  property. This means that all the triples were  is the predicate of the triple will be ignored by this test.

Technical Explanation
In RDF, everything is a triple. A triple is a 3-tuple of the form:. Every record is described by one or more of these triples. The  is the record being described. The  is a property/predicate/attribute of that record. The  is the value of a property.

In RDF, the  can loosely be one of two things: What the  test does is to get the complete list of all the   which are reference to another record. Then, once this list is compiled, the test validates that the  references are described in OSF, in the same, or another dataset/ontology. This heuristic has been implemented as a SPARQL query that is used internally.
 * 1) a   value
 * 2) a reference to another record

Automatic Validation Error Fixing
If the  parameter is specified for a DVT command, then the   test will try to fix all the validation errors that occurred. The fix that will be applied is that the triple where the value is a URI which is not existing in any other dataset, or any other ontologies, will be deleted in the dataset.

However, the DVT uses the Revisioning capabilities of OSF when it does the automatic fixing of errors. This means that it will always be possible to revert changes performed by the DVT by using the revisioning web service endpoints.

Fixing Exceptions
There is one kind of triple that cannot be fixed by this  check. If the predicate of a value that is not existing is, then this triple won't be fixed. It will be reported to the user interface and in the XML or the JSON logs, but it won't be fixed.

The reason why it won't be fixed is simple, it is because if we remove the  associated with a record, then we will untype that record unnecessarily. What we do is to report the issue such that the data maintainers does fix the type by hands, or does create the class, representing that type, into one of the loaded ontologies.

Logging Error Fixes
All the fixes are logged into the XML or JSON log files if the  and/or the   options were specified in the DVT command. In this section we will explain how to interpret the log files specifically for the fixes reported in the logs for that  check.

XML Logs Files
Here is the explanation for the meaning of each element of that file:

Here is an example of such a (partial) XML log file that includes the fixes reports:

JSON Logs Files
Here is the explanation for the meaning of each element of that file:

Here is an example of such a (partial) JSON log file that includes the fixes reports:

Errors
{| border="1" cellpadding="5" cellspacing="0" !

URI-EXISTENCE-100

 * Description
 * This error is returned when a URI if used as an  reference but that is not currently defined in any dataset accessible by the DVT. This means that an "undefined" URI has been referenced by another record within the datasets.
 * Fields
 * }
 * Fields
 * }
 * }

Warnings
{| border="1" cellpadding="5" cellspacing="0" !

URI-EXISTENCE-50

 * Description
 * This warning is returned when the test couldn't check if referenced URIs exists in the OSF instance. This means that the SPARQL query failed to execute the query.
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

{| border="1" cellpadding="5" cellspacing="0" !

URI-EXISTENCE-51

 * Description
 * We couldn't get the list of affected records from the OSF instance.
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

{| border="1" cellpadding="5" cellspacing="0" !

URI-EXISTENCE-52

 * Description
 * We couldn't read the description of an affected record from the OSF instance.
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

{| border="1" cellpadding="5" cellspacing="0" !

URI-EXISTENCE-53

 * Description
 * We couldn't update the description of an affected record from the OSF instance
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

Property Validation
Properties, the middle part of an RDF triple, may be one of three kinds: 1), for which the object is a value that conforms to a specific type of data type; 2)  , for which the object is another instance denoted by a URI; or 3) an  , where the object is a literal (string) value. Both   and   may be further defined using the concepts of   and  , as described below. Annotation properties do not have domains or ranges. This section describes how the DVT validates against   and.

Introduction
The  test is to check if all of the datatypes defined for all used datatype properties have been respected and are valid. With this test, we make sure that all the expected value types have been respected when indexed into OSF.

How it Works
The heuristic used by this check is as follows: Notes regarding this heuristic:
 * 1) Get the list of all the properties that have a non-URI value and that have a   defined for them in one of the loaded ontologies
 * 2) For each datatype property we get the list of all the values. At this step, we will have two pieces of information about the value. We will have the actual textual value, and the datatype of that value as defined in the triple store.
 * 3) For each value we make sure that the datatype defined for that value in the triple store is the same as the one defined in the ontology
 * 4) If the value's defined datatype is the same as the one defined in the ontology, then we validate the actual value according to internal XSD and RDFS data validation internal procedures
 * 5) If the actual value is not valid according to these internal validation tests, we return a   error
 * 6) If the value's defined datatype is not the same as the one defined in the ontology, we return a   error
 * 1) If no range is defined for a property, then its range is considered " ", which means that no specific datatype is defined for the value, and that any value can be used as a value of this property.
 * 2) Even if a value is defined as   in the triple store, it doesn't mean that the value is actually a valid   since the triple store won't validate according to this datatype, but will only tag the value as being of that type. So this is why we have to perform the test

Technical Explanation
In RDF, everything is a triple. A triple is a 3-tuple of the form:. Every record is described by one or more of these triples. The  is the record being described. The  is a property/predicate/attribute of that record. The  is the value of a property.

OWL is a specification framework that is used to create the ontologies that are used to define the semantics of the properties/predicates/attributes and the types/classes used to describe the instance records indexed in CCR datasets.

When we define a  in an ontology, each predicate may have at least two different characteristics: The  of a property is the left side of the property. What the  does is to specify where the   can be used, which type/kind of   it can be used to describe. That is, the  for a given property defines valid subject types to which it applies. If a  type is not in the   of a property, then that property cannot be used to describe that type of.
 * 1) It may have a
 * 2) It may have a

The  of a property is the right side of the property. What the does is to specify the datatype of the value  of such a. That is, the range for a given property defines valid object types to which it can apply. For example, if we have a  property where the range of that property is , then it means that all the instance records that uses this   property need to have a value of type.

Specifying within an Ontology
For this data validation test to work, the ontologies loaded in OSF have to be properly defined. If no datatypes are defined for any property, then the test will consider that their default datatype is  which is equivalent to say that any value can be entered for each of the properties. Otherwise, any datatype specified into any loaded ontology will have a direct impact on this test.

When you edit an ontology into Protégé, you have a series of tabs. One of which is called "Data Properties". This is the tab where all the datatype properties defined in the ontology will appear. If you click on any of these datatype properties that appears on the left side of the application, you will see the property's complete description appearing on the right side of the application.

There is one section that is highlighted on the right side section that is of interest for this test, which is the  section. This is where the  of a property is defined in Protégé. There are 3 buttons related to such a range that interest us particularly: To add a new datatype to a given property, you have to click the  button. When clicked, a list of available datatypes will then appear. From that list, you choose the datatype you want to specify for this property and click the  button.Once you added/modified/removed a datatype assignation to a property, you have to reload the ontology in OSF to have the modification taken into account by the DVT.
 * – The add button is used to add a new datatype range to the property
 * – The edit button is used to edit the current datatype range assignation of the property
 * – The remove button is used to remove a datatype range assignation of the property

Supported Datatypes
This validation test does perform additional internal data validation procedure to make sure that the value is a valid value according to the specified datatype. Here is a list of all the supported datatypes:
 * 1) xsd:anyURI
 * 2) xsd:base64Binary
 * 3) xsd:boolean
 * 4) xsd:byte
 * 5) xsd:dateTime
 * 6) xsd:dateTimeStamp
 * 7) xsd:decimal
 * 8) xsd:double
 * 9) xsd:float
 * 10) xsd:hexBinary
 * 11) xsd:int
 * 12) xsd:integer
 * 13) xsd:language
 * 14) xsd:long
 * 15) xsd:Name
 * 16) xsd:NCName
 * 17) xsd:negativeInteger
 * 18) xsd:NMTOKEN
 * 19) xsd:nonNegativeInteger
 * 20) xsd:nonPositiveInteger
 * 21) xsd:normalizedString
 * 22) xsd:positiveInteger
 * 23) xsd:short
 * 24) xsd:string
 * 25) xsd:token
 * 26) xsd:unsignedByte
 * 27) xsd:unsignedInt
 * 28) xsd:unsignedLong
 * 29) xsd:unsignedShort
 * 30) rdfs:Literal
 * 31) rdf:PlainLiteral
 * 32) rdf:XMLLiteral

Errors
{| border="1" cellpadding="5" cellspacing="0" !

DATATYPE-PROPERTIES-DATATYPE-100
{| border="1" cellpadding="5" cellspacing="0" !
 * Description
 * This error is returned when the datatype specified in the triple store and the range specified in the ontology for that property are different.
 * Fields
 * }
 * Fields
 * }
 * }

DATATYPE-PROPERTIES-DATATYPE-101

 * Description
 * This error is returned when the datatype specified in the triple store and the range specified in the ontology for that property are the same, but when the actual indexed value is invalid according to the internal datatype validation procedures.
 * Fields
 * }
 * Fields
 * }
 * }

Warnings
{| border="1" cellpadding="5" cellspacing="0" !

DATATYPE-PROPERTIES-DATATYPE-50

 * Description
 * This warning is returned when a datatype property is being used, but for which we don't have any  defined for it in any loaded ontologies. No immediate actions are required when this warning is sent, but they show areas where the ontologies may be updated/improved.
 * Fields
 * Fields
 * Fields


 * }

{| border="1" cellpadding="5" cellspacing="0" !

DATATYPE-PROPERTIES-DATATYPE-51

 * Description
 * This warning is returned when we couldn't get the list of datatype properties from the structWSF instance. The SPARQL query failed in some way.
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

{| border="1" cellpadding="5" cellspacing="0" !

DATATYPE-PROPERTIES-DATATYPE-52

 * Description
 * This warning is returned when we couldn't get the list of values for a specific property
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

Introduction
The  test is to check if all the properties are used to describe the proper instance records currently indexed in OSF as defined into the loaded ontologies. Not all the properties can be used to describe all the type of instance records, so this test make sure that all the properties have been used to define the proper type of instance records.

How it Works
The heuristic used by this check is as follows: Notes regarding this heuristic:
 * 1) Get the list of all the properties that are used to describe any record within OSF
 * 2) For each of the property we get the list of all the distinct types of all the records that uses this property.
 * 3) For each type we make sure that the type belongs to the domain defined for this property in the loaded ontologies
 * 4) If the the type of one of the record doesn't belong to the domain of the property as described in the ontologies, then a   error will be returned
 * 1) If no   is defined for a property, than its   is considered " " which means that any type of instance records can use this property

Technical Explanation
In RDF, everything is a triple. A triple is a 3-tuple of the form:. Every record is described by one or more of these triples. The  is the record being described. The  is a property/predicate/attribute of that record. The  is the value of a property.

OWL is a specification framework that is used to create the ontologies that are used to define the semantic of the properties/predicates/attributes and the types/classes used to describe the instance records indexed in OSF datasets.

When we define a  in an ontology, each predicate have at least two different characteristics: The  of a property is the left side of the property. What the  does is to specify where the   can be used, which type/kind of   it can be used to describe. If a  type is not in the   of a property, then that property cannot be used to describe that type of.
 * 1) It does have a
 * 2) It does have a

The  of a property, is the right side of the property. What the range does is to specify the datatype of the value of such a. For example, if we have a  property where the range of that property is , then it means that all the instance records that uses this   property need to have a value of type.

Specifying within an Ontology
For this data validation test to work, the ontologies loaded in OSF have to be properly defined. If no domains are defined for any property, then the test will consider that their default domains is  which is equivalent to say that any property can be used to define any type of instance record. Otherwise, any domain specified into any loaded ontology will have a direct impact on this test.

When you edit an ontology into Protégé, you have a series of tabs. One of which is called " " and another one which is called " ". These are the tabs where all the object and datatype properties are defined in the ontology will appear. If you click on any of these properties that appears on the left side of the application, you will see the property's complete description appearing on the right side of the application.

Note that the following explanations are the same for the object, or the datatype properties sections. However, the current example is based on the " " tab.

There is one section that is highlighted on the right side section that is of interest for this test, which is the  section. This is where the  of a property is defined in Protégé. There are 3 buttons related to such a domain that interest us particularly:
 * – The add button is used to add a new domain to the property
 * – The edit button is used to edit the current domain assignation of the property
 * – The remove button is used to remove a domain assignation of the property

To add a new domain to a given property, you have to click the "+" button. When clicked, a list of available domain types will appear under the  tab. From that list, you choose the type (class) you want to specify for this property and click the "OK" button.Once you add/modify/remove a range assignation to a property, you have to reload the ontology in OSF to have the modification taken into account by the DVT.

Errors
{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-DATATYPE-PROPERTIES-DOMAIN-100

 * Description
 * This error is returned when the type of a record is not part of the domain of a property used to describe the record.
 * Fields
 * }
 * Fields
 * }
 * }

Warnings
{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-DATATYPE-PROPERTIES-DOMAIN-50
defined for it in any loaded ontologies. No immediate action is required when this warning is sent, but the error shows areas where the ontologies may be updated/improved.
 * Description
 * This warning is returned when a property is being used, but for which we don't have any
 * This warning is returned when a property is being used, but for which we don't have any
 * Fields
 * }
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-DATATYPE-PROPERTIES-DOMAIN-51
properties of a given type from the CCR. This means that the Ontology: Read query failed in some way.
 * Description
 * This warning is returned when the test couldn't get the list of super
 * This warning is returned when the test couldn't get the list of super
 * Fields
 * }
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-DATATYPE-PROPERTIES-DOMAIN-52

 * Description
 * This warning is returned when we couldn't find the ontology where a specific type has been defined
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-DATATYPE-PROPERTIES-DOMAIN-53

 * Description
 * This warning is returned when we couldn't get the list of available datatype and object properties. This means that the SPARQL query failed in some way.
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-DATATYPE-PROPERTIES-DOMAIN-54

 * Description
 * This warning is returned when we couldn't get the list of available datatype and object properties. This means that the SPARQL query failed in some way.
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-DATATYPE-PROPERTIES-DOMAIN-55

 * Description
 * This warning is returned when we couldn't get the list of affected records by an error that got raised. This means that the SPARQL query failed in some way.
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

Introduction
The  test is to check if all the ranges of the object properties have been respected in OSF. With this test, we make sure that every time that an object property is used to describe a record, that it references a valid record. For example, if we have a  object property that has a range of , then we make sure that every time the property is used, that it refers to a record of type. If it is not the case, then errors are reported.

How it Works
The heuristic used by this check is as follows: Notes regarding this heuristic:
 * 1) Get the list of all the object properties that are used to describe records
 * 2) For each of the object property we get the list of all the values (URIs of referenced records)
 * 3) For each URI we make sure that the type of the referenced record comply with the range defined for that property defined in the loaded ontologies. This check is performed using inference
 * 4) If the type of the URI is not part of the range of the property, then an error   is reported
 * 1) If no  is defined for an object property, than its range is considered " " which means that any type of record can be referenced by that property.
 * 2) The   validation check is using inference. This means that if we have a   page record that uses a property   property which is defined such that its range is , then this triple will be valid since the   is a sub-class-of.

Technical Explanation
In RDF, everything is a triple. A triple is a 3-tuple of the form:. Every record is described by one or more of these triples. The  is the record being described. The  is a property/predicate/attribute of that record. The  is the value of a property.

OWL is a specification framework that is used to create the ontologies that are used to define the semantics of the properties/predicates/attributes and the types/classes used to describe the instance records indexed in OSF datasets.

When we define a  in an ontology, each predicate have at least two different characteristics: The  of a property is the left side of the property. What the  does is to specify where the   can be used, which type/kind of   it can be used to describe. If a  type is not in the   of a property, then that property cannot be used to describe that type of.
 * 1) It may have a
 * 2) It may have a

The  of a property, is the right side of the property. What the range does is to specify the datatype of the value of such a. For example, if we have a  object property where the range of that property is , then it means that all the instance records that uses this   property need to reference an instance record of type.

Specifying within an Ontology
For this data validation test to work, the ontologies loaded IN OSF have to be properly defined. If no range are defined for any object property, then the test will consider that their default range is  which is equivalent to say that this object property can be used to reference any type of instance records. Otherwise, any range specified for any object property into any loaded ontology will have a direct impact on this test.

When you edit an ontology into Protégé, you have a series of tabs. One of which is called " ". This is the tab where all the object properties defined in the ontology will appear. If you click on any of these object properties that appears on the left side of the application, you will see the property's complete description appearing on the right side of the application.

There is one section that is highlighted on the right side section that is of interest for this test, which is the  section. This is where the  of a property is defined in Protégé. There are 3 buttons related to such a range that interest us particularly:
 * – The add button is used to add a new range to the object property
 * – The edit button is used to edit the current range assignation of the object property
 * – The remove button is used to remove a range assignation of the object property

To add a new class to the range of a given property, you have to click the "+" button. When clicked, a list of available classes will then appear. From that list, you choose the class you want to specify for this object property and click the "OK" button.Once you added/modified/removed a range assignation to an object property, you have to reload the ontology in OSF to have the modification taken into account by the DVT.

Errors
{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-PROPERTIES-RANGE-100
record that has ha type which doesn't belong to the range defined for that object property has defined in the loaded ontologies
 * Description
 * This error is returned when there is an object property that references a
 * This error is returned when there is an object property that references a
 * Fields
 * }
 * }
 * }

Warnings
{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-PROPERTIES-RANGE-50

 * Description
 * This warning is returned when a property is being used, but for which we don't have any  defined for it in any loaded ontologies. No immediate action is required when this warning is sent, but the error shows areas where the ontologies may be updated/improved.
 * Fields
 * }
 * Fields
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

DATATYPE-PROPERTIES-DATATYPE-51

 * Description
 * This warning is returned when we couldn't get the list super classes for one of the type of the referenced record
 * Fields
 * }
 * Fields
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-PROPERTIES-RANGE-52

 * Description
 * This warning is returned when we couldn't find the ontology where a specific type has been defined
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-PROPERTIES-RANGE-53

 * Description
 * This warning is returned when we couldn't get the list of object properties from the OSF instance
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-PROPERTIES-RANGE-54

 * Description
 * This warning is returned when we couldn't find the range defined for an object property. This means that the Ontology: Read query failed in some way
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OBJECT-PROPERTIES-RANGE-55

 * Description
 * This warning is returned when we couldn't get the list of affected records by an error that got raised. This means that the SPARQL query failed in some way.
 * Fields
 * No additional fields
 * }
 * No additional fields
 * }

OWL Cardinality
The OWL language enables one to define the number of items a given property may have, known as. This section describes these DVT tests.

Introduction
The test is used to check if a given property (datatype or object) is used the exact number of times specified to define a record of a specific type. As we will see below, this validation test can also be used to restrict the usage of a property to describe a record of a specific type.

How it Works
The heuristic used by this check is as follows:
 * 1) Get the list of all the datatype properties which have an exact cardinality restriction defined with them
 * 2) For each of the exact cardinality restriction, we get the list of all the records that uses that property
 * 3) For each of them, we make sure that all the records of the type of the restriction uses that exact number of properties
 * 4) If some record doesn't, then we report a   error for each of them
 * 5) For each of the exact cardinality restriction, we get the list of all the records of the type of the restriction that are not using that property
 * 6) If the exact cardinality is not 0, then we report a   error
 * 7) For each of the exact cardinality restriction, we get the list of all the values related by the class & property defined in the restriction
 * 8) If the value doesn't belong to the Datatype specified in the restriction, then we report a   error
 * 9) Get the list of all the object properties which have an exact cardinality restriction defined with them
 * 10) For each of the exact cardinality restriction, we get the list of all the records that uses that property
 * 11) For each of them, we make sure that all the records of the type of the restriction uses that exact number of properties
 * 12) If some record doesn't, then we report a   error for each of them
 * 13) For each of the exact cardinality restriction, we get the list of all the records of the type of the restriction that are not using that property
 * 14) If the exact cardinality is not 0, then we report a   error

Technical Explanation
In OWL, there is a concept call  which is used to restrict the association of properties to a particular class extension (a particular set of classes). In other words, this Restriction mechanism is used to state how the properties (object or datatype) should be used, so they should be used to describe what kind of instance records. A restriction has three characteristics: Let's take an example to illustrate an exact cardinality restriction. In OWL+XML code, we would have a restriction like this:
 * 1) It is applied to a
 * 2) It specifies which   or   that is being restricted
 * 3) It specifies the expected type of values
 * 4) The class of things that can be referenced by an object property
 * 5) The datatype that define the values of a datatype property

What this restriction means is:
 * When we describe a record of type, we have to have a   property where its value is a record of type  . We are restricted to have a single of these triples. If we have none, then we have a validation issue, and if we have more than one, then we have a validation issue as well.

Specifying within an Ontology
For this data validation test to work, the ontologies loaded in OSF have to be properly defined. If no exact cardinality restrictions are defined for any class, then nothing will be tested related to the exact cardinality restrictions. Otherwise, any exact cardinality restriction defined in loaded ontologies will force this test to test all the affected records according to this restriction.

When you edit an ontology into Protégé, you have a series of tabs. One of which is called " ". This is the tab where all the classes defined in the ontology will appear. If you click on any of these class that appears on the left side of the application, you will see the class's complete description appearing on the right side of the application.

There is one section that is highlighted on the right side section that is of interest for this test, which is the  section. This is where an exact cardinality restriction is defined in Protégé. There are 3 buttons related to such a range that interest us particularly:
 * – The add button is used to add a new sub-class-of of a given class
 * – The edit button is used to edit a sub-class-of of a given class
 * – The remove button is used to delete a sub-class-of of a given class

To add a new exact cardinality restriction on an object property, you have to click the  button at the right of the   section. Clicking this button, a new contextual window will appear. From that window, you will have to select the  tab. This tab has all the information you need to create a new exact cardinality restriction for the selected class (in this case, it is the  class).

What you have to do once you clicked that tab is: To add a new exact cardinality restriction on a datatype property, you have to click the  button at the right of the   section. Clicking this button, a new contextual window will appear. From that window, you will have to select the  tab. This tab has all the information you need to create a new exact cardinality restriction for the selected class (in this case, it is the  class).
 * 1) Select the object property you want to create a restriction for from the left list called
 * 2) Then select the type of records that can be referenced by that property from the   right section
 * 3) Then you have to select the restriction type   from the   section
 * 4) Finally you have to specify the cardinality number, and click the   button to save the new restriction

What you have to do once you clicked that tab is: One thing that is important to understand is that all the sub-classes of a class where an exact cardinality restriction is defined will inherit that same restriction. This is what you can see in the " " section that we highlighted in yellow in the screenshot above. All three restrictions that appear in that section come from restrictions defined in parent classes of the  class. In this specific case, the  restriction has been defined in the   class. The  and   restrictions have been defined in the   class.
 * 1) Select the datatype property you want to create a restriction for from the left list called
 * 2) Then select the datatype of that property from the   right section
 * 3) Then you have to select the restriction type   from the   section
 * 4) Finally you have to specify the cardinality number, and click the   button to save the new restriction

This inheritance behavior is quite important. That way, you can define an exact cardinality restriction on a class in the upper end of an ontology's class hierarchy and have the cardinality applied to all the sub-classes of that super-class. This means that you don't have to specify that restriction on all and every classes, but only on the parent one(s).

Usage
When you define an exact cardinality restriction on a class, you are trying to accomplish one of the following things:
 * 1) If the exact cardinality is 0, it means that you want to specify that the usage that property is prohibited on that class. This means that you cannot use that property to describe records of that type. If you define such a 0 cardinality, it means that you want to use the DVT to make sure that people are not using a certain property to define a certain type of records
 * 2) If the exact cardinality is bigger than 0, it means that you want to specify that every time you describe a record of that type, then you want that number of this property to describe the record

Errors
{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-EXACT-100

 * Description
 * This error is returned when there is a record of a certain type that is not complying with the exact cardinality restriction for a datatype property as defined in one of the loaded ontologies
 * Fields
 * }
 * Fields
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-EXACT-101

 * Description
 * This error is returned when there is a record of a certain type that is not complying with the exact cardinality restriction for a object property as defined in one of the loaded ontologies
 * Fields
 * }
 * Fields
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-EXACT-102

 * Description
 * This error is returned when there is a record of a certain type that has no property defining it such that it doesn't comply with the exact cardinality restriction greater than 0 for a datatype property as defined in one of the loaded ontologies
 * Fields
 * }
 * Fields
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-EXACT-103

 * Description
 * This error is returned when there is a record of a certain type that has no property defining it with a proper exact cardinality restriction (that is, greater than 0) for an object property as defined in one of the loaded ontologies
 * Fields
 * }
 * Fields
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-EXACT-104

 * Description
 * This error is returned when there is at least one record that uses a datatype property using the exact cardinality restriction and for which there is none that comply with the specified datatype as describe by the restriction.
 * Fields
 * }
 * Fields
 * }
 * }

Warnings
{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-EXACT-50

 * Description
 * This warning is returned when e couldn't get the cardinality restriction on the datatype property from the OSF instance. This means that the SPARQL query failed in some way
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-EXACT-51

 * Description
 * This warning is returned when we couldn't get the number of properties, per record, that have been indexed in the triple store. This means that the SPARQL query failed in some way
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-EXACT-52

 * Description
 * This warning is returned when we couldn't get the number of properties, per record, that have been indexed in the triple store. This means that the SPARQL query failed in some way
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-EXACT-53

 * Description
 * This warning is returned when we couldn't get the number of properties, per record, that have been indexed in the triple store. This means that the SPARQL query failed in some way
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-EXACT-54

 * Description
 * This warning is returned when e couldn't get the cardinality restriction on the object property from the OSF instance. This means that the SPARQL query failed in some way
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-EXACT-55

 * Description
 * This warning is returned when we couldn't get the list of values for a given datatype property
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

OWL Maximum Cardinality Restriction Validation
The test is used to check if a given property (datatype or object) is used the maximum number of times to define a record of a specific type.

How it Works
The heuristic used by this check is as follows:
 * 1) Get the list of all the datatype properties which have a a maximum cardinality restriction defined with them
 * 2) For each of the maximum cardinality restriction, we get the list of all the records that uses that property
 * 3) For each of them, we make sure that all the records of the type of the restriction uses that maximum number of properties
 * 4) If some record doesn't, then we report a   error for each of them
 * 5) For each of the maximum cardinality restriction, we get the list of all the values related by the class & property defined in the restriction
 * 6) If the value doesn't belong to the Datatype specified in the restriction, then we report a   error
 * 7) Get the list of all the object properties which have an exact cardinality restriction defined with them
 * 8) For each of the exact cardinality restriction, we get the list of all the records that uses that property
 * 9) For each of them, we make sure that all the records of the type of the restriction uses that exact number of properties
 * 10) If some record doesn't, then we report a   error for each of them

Technical Explanation
In OWL, there is a concept called  which is used to restrict the association of properties to a particular class extension (a particular set of classes). In other words, this Restriction mechanism is used to state how the properties (object or datatype) should be used, so they should be used to describe what kind of instance records. A restriction has three characteristics: Let's take an example to illustrate a maximum cardinality restriction. In OWL+XML code, we would have a restriction like this:
 * 1) It is applied to a
 * 2) It specifies which   or   that is being restricted
 * 3) It specifies the expected type of values:
 * 4) The class of things that can be referenced by an object property
 * 5) The datatype that define the values of a datatype property

What this restriction means is:
 * When we describe a record of type, we have to have a   property where its value is a record of datatype  . We are restricted to have a maximum of one of these triple.

Specifying within an Ontology
For this data validation test to work, the ontologies loaded in OSF have to be properly defined. If no maximum cardinality restrictions are defined for any class, then nothing will be tested related to the maximum cardinality restrictions. Otherwise, any maximum cardinality restriction defined in loaded ontologies will force this test to test all the affected records according to this restriction.

When you edit an ontology into Protégé, you have a series of tabs. One of which is called " ". This is the tab where all the classes defined in the ontology will appear. If you click on any of these class that appears on the left side of the application, you will see the class's complete description appearing on the right side of the application.

There is one section that is highlighted on the right side section that is of interest for this test, which is the  section. This is where an maximum cardinality restriction is defined in Protégé. There are 3 buttons related to such a range that interest us particularly:
 * – The add button is used to add a new sub-class-of of a given class
 * – The edit button is used to edit a sub-class-of of a given class
 * – The remove button is used to delete a sub-class-of of a given class

To add a new maximum cardinality restriction on an object property, you have to click the  button at the right of the   section. Clicking this button, a new contextual window will appear. From that window, you will have to select the  tab. This tab has all the information you need to create a new maximum cardinality restriction for the selected class (in this case, it is the  class).

What you have to do once you clicked that tab is: To add a new maximum cardinality restriction on a datatype property, you have to click the  button at the right of the   section. Clicking this button, a new contextual window will appear. From that window, you will have to select the  tab. This tab has all the information you need to create a new maximum cardinality restriction for the selected class (in this case, it is the  class).
 * 1) Select the object property you want to create a restriction for from the left list called
 * 2) Then select the type of records that can be referenced by that property from the   right section
 * 3) Then you have to select the restriction type   from the   section
 * 4) Finally you have to specify the cardinality number, and click the   button to save the new restriction

What you have to do once you clicked that tab is: One thing that is important to understand is that all the sub-classes of a class where an maximum cardinality restriction is defined will inherit that same restriction. This is what you can see in the " " section that we highlighted in yellow in the screenshot above. All the three restrictions that appears in that section comes from restrictions defined in parent classes of the  class. In this specific case, the  restriction has been defined in the   class. The  and   restrictions have been defined in the   class.
 * 1) Select the datatype property you want to create a restriction for from the left list called
 * 2) Then select the datatype of that property from the   right section
 * 3) Then you have to select the restriction type   from the   section
 * 4) Finally you have to specify the cardinality number, and click the   button to save the new restriction

This inheritance behavior is quite important. That way, you can define an maximum cardinality restriction on a class in the upper end of an ontology's class hierarchy and have the cardinality applied to all the sub-classes of that super-class. This means that you don't have to specify that restriction on all and every classes, but only on the parent one(s).

Usage
When you define a maximum cardinality restriction on a class, specify that if a property (the one related to the restriction) is being used to describe a record of a certain type (the one related to the restriction) then you can use it a maximum of time has specified by the maximum cardinality restriction on that property.

Errors
{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-MAX-100

 * Description
 * This error is returned when there is a record of a certain type that is not complying with the maximum cardinality restriction for a datatype property has defined in one of the loaded ontologies
 * Fields
 * }
 * Fields
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-MAX-101

 * Description
 * This error is returned when there is a record of a certain type that is not complying with the maximum cardinality restriction for a object property as defined in one of the loaded ontologies
 * Fields
 * }
 * Fields
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-MAX-102

 * Description
 * This error is returned when there is at least one record that uses a datatype property using the maximum cardinality restriction and for which there is none that comply with the specified datatype as describe by the restriction.
 * Fields
 * }
 * Fields
 * }
 * }

Warnings
{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-MAX-50

 * Description
 * This warning is returned when e couldn't get the cardinality restriction on the datatype property from the structWSF instance. This means that the SPARQL query failed in some way
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-MAX-51

 * Description
 * This warning is returned when we couldn't get the number of properties, per record, that have been indexed in the triple store. This means that the SPARQL query failed in some way
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-MAX-52

 * Description
 * This warning is returned when e couldn't get the cardinality restriction on the object property from the structWSF instance. This means that the SPARQL query failed in some way
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-MAX-53

 * Description
 * We couldn't get sub-classes of class expression from the structWSF instance
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-MAX-54

 * Description
 * This warning is returned when we couldn't get the number of properties, per record, that have been indexed in the triple store. This means that the SPARQL query failed in some way
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-MAX-55

 * Description
 * This warning is returned when we couldn't get the list of values for a given datatype property
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

OWL Existential Restriction Validation
The test is used to check if a given datatype property is used to describe a record of a certain type, then that at least one of its value is using the datatype defined in the restriction. It can also be used to check if a given object property is used to describe a record of a certain type, then that at least one of its value is referencing a record of the type defined in the restriction.

How it Works
The heuristic used by this check is as follows:
 * 1) Get the list of all the datatype properties which have an existential restriction defined for them
 * 2) For each of the existential restriction, we get the list of all the records that uses that property
 * 3) For each of them, we make sure that all the records of the type of the restriction, that uses that property, has at least one value of the defined datatype
 * 4) If some record doesn't, then we report a   error for each of them
 * 5) For each of the exact cardinality restriction, we get the list of all the values related by the class & property defined in the restriction
 * 6) If the value doesn't belong to the Datatype specified in the restriction, then we report a   error
 * 7) Get the list of all the object properties which have an existential restriction defined for them
 * 8) For each of the existential restriction, we get the list of all the records that uses that property
 * 9) For each of them, we make sure that all the records of the type of the restriction, that uses that property, has at least one value of the defined type
 * 10) If some record doesn't, then we report a   error for each of them

Technical Explanation
In OWL, there is a concept call  which is used to restrict the association of properties to a particular class extension (a particular set of classes). In other words, this Restriction mechanism is used to state how the properties (object or datatype) should be used, so they should be used to describe what kind of instance records. A restriction has three characteristics: Let's take an example to illustrate an existential restriction. In OWL+XML code, we would have a restriction like this:
 * 1) It is applied to a
 * 2) It specifies which   or   that is being restricted
 * 3) It specifies the expected type of values:
 * 4) The class of things that can be referenced by an object property
 * 5) The datatype that define the values of a datatype property

What this restriction means is:
 * When we describe a record of type, we have to have a   property where its value is a record of type  . If a record of type   is described using the   property, then we are restricted to have a minimum of one of the values of this property to be of type.

Specifying within an Ontology
For this data validation test to work, the ontologies loaded in OSF have to be properly defined. If no existential restrictions are defined for any class, then nothing will be tested related to the existential restrictions. Otherwise, any existential restriction defined in loaded ontologies will force this test to test all the affected records according to this restriction.

When you edit an ontology into Protégé, you have a series of tabs. One of which is called " ". This is the tab where all the classes defined in the ontology will appear. If you click on any of these class that appears on the left side of the application, you will see the class's complete description appearing on the right side of the application.

There is one section that is highlighted on the right side section that is of interest for this test, which is the  section. This is where an existential restriction is defined in Protégé. There are 3 buttons related to such a range that interest us particularly:
 * – The add button is used to add a new sub-class-of of a given class
 * – The edit button is used to edit a sub-class-of of a given class
 * – The remove button is used to delete a sub-class-of of a given class

To add a new existential restriction on an object property, you have to click the  button at the right of the   section. Clicking this button, a new contextual window will appear. From that window, you will have to select the  tab. This tab has all the information you need to create a new existential restriction for the selected class (in this case, it is the  class).

What you have to do once you clicked that tab is: To add a new existential restriction on a datatype property, you have to click the  button at the right of the   section. Clicking this button, a new contextual window will appear. From that window, you will have to select the  tab. This tab has all the information you need to create a new existential restriction for the selected class (in this case, it is the  class).
 * 1) Select the object property you want to create a restriction for from the left list called
 * 2) Then select the type of records that can be referenced by that property from the   right section
 * 3) Then you have to select the restriction type   from the   section
 * 4) Finally you have to specify the cardinality number, and click the   button to save the new restriction

What you have to do once you clicked that tab is: One thing that is important to understand is that all the sub-classes of a class where an existential restriction is defined will inherit that same restriction. This is what you can see in the " " section that we highlighted in yellow in the screenshot above. All the three restrictions that appears in that section comes from restrictions defined in parent classes of the  class. In this specific case, the  restriction has been defined in the   class. The  and   restrictions have been defined in the   class.
 * 1) Select the datatype property you want to create a restriction for from the left list called
 * 2) Then select the datatype of that property from the   right section
 * 3) Then you have to select the restriction type   from the   section

This inheritance behavior is quite important. That way, you can define an existential restriction on a class in the upper end of an ontology's class hierarchy and have the cardinality applied to all the sub-classes of that super-class. This means that you don't have to specify that restriction on all and every classes, but only on the parent one(s).

Usage
When you define an existential restriction on a class, you are specifying that if a certain property is used to describe a record of that type, then you have to have at least one of its value to be the restricted value by the restriction.

Errors
{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-SOME-100
error is returned when there is a record of a certain type that is not complying with the existential restriction for a datatype property as defined in one of the loaded ontologies
 * Description
 * This
 * This
 * Fields
 * }
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-SOME-101
error is returned when there is a record of a certain type that is not complying with the existential restriction for a object property as defined in one of the loaded ontologies
 * Description
 * This
 * This
 * Fields
 * }
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-SOME-102
error is returned when there is at least one record that uses a datatype property using the existential restriction and for which there is none that comply with the specified datatype as describe by the restriction.
 * Description
 * This
 * This
 * Fields
 * }
 * }
 * }

Warnings
{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-SOME-50
warning is returned when we couldn't get the list of existential restrictions from the structWSF instance. This means that the SPARQL query failed in some way
 * Description
 * This
 * This
 * Fields
 * No additional fields specified
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-SOME-51
warning is returned when we couldn't get the number of properties, per record, that have been indexed in the triple store. This means that the SPARQL query failed in some way
 * Description
 * This
 * This
 * Fields
 * No additional fields specified
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-SOME-52
warning is returned when we couldn't get the number of properties, per record, that have been indexed in the triple store. This means that the SPARQL query failed in some way
 * Description
 * This
 * This
 * Fields
 * No additional fields specified
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-SOME-53

 * Description
 * This warning is returned when we couldn't get sub-classes of class expression from the structWSF instance
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-SOME-54

 * Description
 * This warning is returned when we couldn't get sub-classes of class expression from the structWSF instance
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-SOME-55

 * Description
 * This warning is returned when we couldn't get the list of values for a given datatype property
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

OWL Universal Restriction Validation
The test is used to check if a given datatype property is used to describe a record of a certain type, then all its value have to use the datatype defined in the restriction. It can also be used to check if a given object property is used to describe a record of a certain type, then all its values have to be of the type defined in the restriction.

How it Works
The heuristic used by this check is as follows:
 * 1) Get the list of all the datatype properties which have a universal restriction defined for them
 * 2) For each of the universal restriction, we get the list of all the records that uses that property
 * 3) For each of them, we make sure that all the values of all the records are of the datatype defined in the description
 * 4) If some record doesn't, then we report a   error for each of them
 * 5) For each of the exact cardinality restriction, we get the list of all the values related by the class & property defined in the restriction
 * 6) If there is not at least one value that belong to the Datatype specified in the restriction, then we report a   error
 * 7) Get the list of all the object properties which have a universal restriction defined for them
 * 8) For each of the universal restriction, we get the list of all the records that uses that property
 * 9) For each of them, we make sure that all the values of all the records are of the type described in the universal restriction
 * 10) If some record doesn't, then we report a   error for each of them

Technical Explanation
In OWL, there is a concept call  which is used to restrict the association of properties to a particular class extension (a particular set of classes). In other words, this Restriction mechanism is used to state how the properties (object or datatype) should be used, so they should be used to describe what kind of instance records. A restriction has three characteristics: Let's take an example to illustrate an existential restriction. In OWL+XML code, we would have a restriction like this: What this restriction means is:
 * 1) It is applied to a
 * 2) It specifies which   or   that is being restricted
 * 3) It specifies the expected type of values:
 * 4) The class of things that can be referenced by an object property
 * 5) The datatype that define the values of a datatype property
 * When we describe a record of type, we have to have a   property where its value is a record of type  . If a record of type   is described using the   property, then we are restricted to have all the values to be of type of type.

Specifying within an Ontology
For this data validation test to work, the ontologies loaded in OSF have to be properly defined. If no universal restrictions are defined for any class, then nothing will be tested related to the universal restrictions. Otherwise, any universal restriction defined in loaded ontologies will force this test to test all the affected records according to this restriction.

When you edit an ontology into Protégé, you have a series of tabs. One of which is called " ". This is the tab where all the classes defined in the ontology will appear. If you click on any of these class that appears on the left side of the application, you will see the class's complete description appearing on the right side of the application.

There is one section that is highlighted on the right side section that is of interest for this test, which is the  section. This is where an existential restriction is defined in Protégé. There are 3 buttons related to such a range that interest us particularly:
 * – The add button is used to add a new sub-class-of of a given class
 * – The edit button is used to edit a sub-class-of of a given class
 * – The remove button is used to delete a sub-class-of of a given class

To add a new universal restriction on an object property, you have to click the  button at the right of the   section. Clicking this button, a new contextual window will appear. From that window, you will have to select the  tab. This tab has all the information you need to create a new universal restriction for the selected class (in this case, it is the  class).

What you have to do once you clicked that tab is: To add a new universal restriction on a datatype property, you have to click the  button at the right of the   section. Clicking this button, a new contextual window will appear. From that window, you will have to select the  tab. This tab has all the information you need to create a new universal restriction for the selected class (in this case, it is the  class).
 * 1) Select the object property you want to create a restriction for from the left list called
 * 2) Then select the type of records that can be referenced by that property from the   right section
 * 3) Then you have to select the restriction type   from the   section

What you have to do once you clicked that tab is: One thing that is important to understand is that all the sub-classes of a class where a universal restriction is defined will inherit that same restriction. This is what you can see in the " " section that we highlighted in yellow in the screenshot above. All the three restrictions that appears in that section comes from restrictions defined in parent classes of the  class. In this specific case, the  restriction has been defined in the   class. The  and   restrictions have been defined in the   class.
 * 1) Select the datatype property you want to create a restriction for from the left list called
 * 2) Then select the datatype of that property from the   right section
 * 3) Then you have to select the restriction type   from the   section

This inheritance behavior is quite important. That way, you can define  universal restriction on a class in the upper end of an ontology's class hierarchy and have the cardinality applied to all the sub-classes of that super-class. This means that you don't have to specify that restriction on all and every classes, but only on the parent one(s).

Usage
When you define a universal restriction on a class, you are specifying that if a certain property is used to describe a record of that type, then you have to have all its value to be the restricted value by the restriction.

Errors
{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-ONLY-100
error is returned when there is a record of a certain type that is not complying with the universal restriction for a datatype property as defined in one of the loaded ontologies
 * Description
 * This
 * This
 * Fields
 * }
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-ONLY-101
error is returned when there is a record of a certain type that is not complying with the universal restriction for a object property as defined in one of the loaded ontologies
 * Description
 * This
 * This
 * Fields
 * }
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-ONLY-102
error is returned when there is at least one record that uses a datatype property using the existential restriction and for which there is none that comply with the specified datatype as describe by the restriction.
 * Description
 * This
 * This
 * Fields
 * }
 * }
 * }

Warnings
{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-ONLY-50
warning is returned when we couldn't get the list of universal restrictions from the OSF instance. This means that the SPARQL query failed in some way
 * Description
 * This
 * This
 * Fields
 * No additional fields specified
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-ONLY-51
warning is returned when we couldn't get the number of properties, per record, that have been indexed in the triple store. This means that the SPARQL query failed in some way
 * Description
 * This
 * This
 * Fields
 * No additional fields specified
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-ONLY-52
warning is returned when we couldn't get the number of properties, per record, that have been indexed in the triple store. This means that the SPARQL query failed in some way
 * Description
 * This
 * This
 * Fields
 * No additional fields specified
 * }
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-ONLY-53

 * Description
 * This warning is returned when we couldn't get sub-classes of class expression from the structWSF instance
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

{| border="1" cellpadding="5" cellspacing="0" !

OWL-RESTRICTION-ONLY-54

 * Description
 * This warning is returned when we couldn't get the list of values for a given datatype property
 * Fields
 * No additional fields specified
 * }
 * No additional fields specified
 * }

=Automating Data Validation= One way to use the  (DVT) is to be able to automatically run these data validation tests, and then to act upon possible issues. The DVT has been developed with a few features to make such automated testing easier. This section outlines the series of features that have been developed for this purpose, and how they should be used.

Silent Mode
The silent mode should be used by any automatic data validation software. What this feature does is to stop sending tests results to the shell terminal. It mutes all the outputs to the user. To enable this feature, you simply have to append  to the DVT command. It can be done this way:

Validation Tests Logs
All the tests can be logging into a XML and/or a JSON serialized log file. These log files can easily be used by an automated data validation software. Once the DVT command finished, then they will have access to read one of the log files, and then analyze them as required, and take actions depending on what they found within the log file (like sending emails for reviewing, automatically fixing issues, etc.).

XML Logs Files
The logs files can easily be saved on the file system using a log file serialized in XML. Such a log file can be saved using the  command:

What this command does is to save all the output, in XML, into the  located in the   folder. Here is an example of such a (partial) XML log file:

JSON Logs Files
The logs files can easily be saved on the file system using a log file serialized in JSON. Such a log file can be saved using the  command:

What this command does is to save all the output, in JSON, into the  located in the   folder. Here is an example of such a (partial) JSON log file: