
There's a table of constraints made of 21 rows and 10 columns. Each row is splitted in 2 categories, one identified by an uppercase letter and one by the corresponding lowercase. Each category has a name and a code. For each of the 42 categories there are 10 arbitrary values.
Classes:
Data Properties:
No new data properties were defined in this step.
Object Properties:
Before identifying the right ODP to use for this step, we defined two Object Properties to connect elements of the ConstraintValue class to the ones of the Constraint class. We later abandoned this solution.
Most important thing: To guarantee the machine's reusability, we need each value of the constraints to be reified as a singular named individual.
Then, for this step we identified the ODP “List” from ontologydesignpatterns.org:
http://ontologydesignpatterns.org/wiki/Submissions:List
Initially, we defined each constraint as a class, and each value as a named individual of that class. Then, using the “List” ODP, we converted each constraint into an individual of the class “List” and connected the related values asserting the object properties itemOf, firstItemOf, lastItemOf, previousItem. All the inverse properties (hasItem, hasFirstItem, hasLastItem, nextItem) were automatically inferred.
The "list of lists", that is the list of constraints (the first column of the Cahier des Charges), cannot be defined as a list itself, because a list item cannot be at the same time a list, given the explicit disjunction of the two classes in the "List" ODP. Thus, we again resorted to the Sequence ODP to specify the order of the constraints.
The consistency of the model has been checked with the Pellet reasoner. SPARQL queries have been tested using the SPARQL Query tab in Protege. The main Cahier des Charges table has been imported after exporting it in CSV format, then using Clark & Parsia's csv2rdf.
2022, Diego Chillo & Laura Travaglini