RDF Representation of Patterns
Posted: Mon Jun 02, 2014 12:22 am
In the beginning there was Part 2, and Part 2 was good. It was good to express (pun intended) instance data, but it was not good at all to express complex ontological restrictions required for Object Information Models. Constraints were particularly difficult to express in Part 2 language. Section 7.4.2 of Part 7 contains some hideous examples for the simplest restrictions required in an OIM.
The move to First Order Logic saved the day. FOL formulas for template axioms in Part 7 were compact and easily readable to convey complex ontological restriction in a formal way. Scolem constants under the existential quantifier was the key to this success.
But in the move to RDF and OWL template axioms were lost. The concept of a variable you can easily find in rule languages and search languages (for example, ?x in SPARQL). But not in RDF. Even Wikepedia acknowledges this – "the presence of variables in rules goes beyond the RDF Semantics" http://en.wikipedia.org/wiki/Semantic_Web_Rule_Language.
Now it is time to resolve this problem. We've more or less accepted that template axioms are not available in RDF format, but for patterns there is a strict requirement to represent them as reference data.
And what are these patterns? Patterns (Template Signature Patterns of JORD together with Template Information Patterns of IIP group) are no more then next level of templates- with weaker restrictions on axioms. At least this is how I see them.
Patterns have signatures just like templates, but they can have optional roles and several different axioms. Pattern axiom is called its "mapping to templates". So much can be clearly seen from JORD TSP Spec:
https://www.posccaesar.org/svn/projects ... ation.docx (this document probable is not available to general public).
And each particular pattern mapping to the templates is effectively an axiom built from highly specialized base templates, as is clearly seen from the work of IIP group – http://iringsandbox.org:8080/tip/tipmanager .
How it can be implemented (with optional roles and multiple mappings, but without RDF representation yet) can be seen in my .15926 Editor and read in its documentation: http://techinvestlab.ru/files/V4/dot159 ... apping.pdf .
My attempt to design RDF representation for patterns is a third one. There was the first suggestion from Andrew Prosser http://www.15926.org/viewtopic.php?f=3&t=160 and the second one from Hans Teijgeler http://www.15926.org/viewtopic.php?f=29&t=221 .
I'm trying below to keep structure of pattern definition as transparent and human-readable as in Hans' version, but at the same time to describe pattern in terms of mappings and variables, as was initially proposed by Andrew.
The basic idea closely follows the reasoning outlined above. In a pattern definition I'm using dummy RDF subjects, which explicitly represent internal variables (Scolem constants) linking together template instances in the mapping description. Mapping description itself becomes indeed a "pattern" – a structure as closely resembling a final project data structure as possible (the main advantage of Hans' suggestion). Generation of SPARQL queries based on such "patterns" is very straightforward process.
An example illustrating my suggestion is the one developed by Hans - TIP "Hydrostatic Test Pressure" with all its restrictions and mapping to templates preserved. Example of template instances generated from this pattern are also the same as in http://www.15926.org/viewtopic.php?f=29&t=221 .
Suggested representation is only RDF, no attempt to use OWL semantics.
A small tsp ontology is developed for patterns. It includes for classes and two predicates:
tsp:TemplateSignaturePattern – the class to hold patterns.
tsp:TSPRole – the class to hold pattern roles.
tsp:TSPVariable – the class to hold dummy entities representing pattern roles and internal variables (Scolem constants).
tsp:TSPMapping – the class to hold entities representing pattern mappings (template axioms).
tsp:TSPPart – the class to hold subjects which constitute building blocks for pattern mapping, template instances for example.
tsp:hasRole – relation from pattern (domain tsp:TemplateSignaturePattern) to its roles (range tsp:TSPRole).
tsp:hasPattern – relation from mapping (domain tsp:TSPMapping) to the pattern it represents (range tsp:TemplateSignaturePattern).
The entities comprising pattern definition (subjects and predicates) are put in ptrn: namespace. All dummy entities have human readable URIs to ease understanding of a pattern structure.
Full example:
Comments:
Obviously the same method can be used to represent template axioms. Transformation from FOL can be easily automated.
I hope someone will read to this point and give his opinion below.
The move to First Order Logic saved the day. FOL formulas for template axioms in Part 7 were compact and easily readable to convey complex ontological restriction in a formal way. Scolem constants under the existential quantifier was the key to this success.
But in the move to RDF and OWL template axioms were lost. The concept of a variable you can easily find in rule languages and search languages (for example, ?x in SPARQL). But not in RDF. Even Wikepedia acknowledges this – "the presence of variables in rules goes beyond the RDF Semantics" http://en.wikipedia.org/wiki/Semantic_Web_Rule_Language.
Now it is time to resolve this problem. We've more or less accepted that template axioms are not available in RDF format, but for patterns there is a strict requirement to represent them as reference data.
And what are these patterns? Patterns (Template Signature Patterns of JORD together with Template Information Patterns of IIP group) are no more then next level of templates- with weaker restrictions on axioms. At least this is how I see them.
Patterns have signatures just like templates, but they can have optional roles and several different axioms. Pattern axiom is called its "mapping to templates". So much can be clearly seen from JORD TSP Spec:
https://www.posccaesar.org/svn/projects ... ation.docx (this document probable is not available to general public).
And each particular pattern mapping to the templates is effectively an axiom built from highly specialized base templates, as is clearly seen from the work of IIP group – http://iringsandbox.org:8080/tip/tipmanager .
How it can be implemented (with optional roles and multiple mappings, but without RDF representation yet) can be seen in my .15926 Editor and read in its documentation: http://techinvestlab.ru/files/V4/dot159 ... apping.pdf .
My attempt to design RDF representation for patterns is a third one. There was the first suggestion from Andrew Prosser http://www.15926.org/viewtopic.php?f=3&t=160 and the second one from Hans Teijgeler http://www.15926.org/viewtopic.php?f=29&t=221 .
I'm trying below to keep structure of pattern definition as transparent and human-readable as in Hans' version, but at the same time to describe pattern in terms of mappings and variables, as was initially proposed by Andrew.
The basic idea closely follows the reasoning outlined above. In a pattern definition I'm using dummy RDF subjects, which explicitly represent internal variables (Scolem constants) linking together template instances in the mapping description. Mapping description itself becomes indeed a "pattern" – a structure as closely resembling a final project data structure as possible (the main advantage of Hans' suggestion). Generation of SPARQL queries based on such "patterns" is very straightforward process.
An example illustrating my suggestion is the one developed by Hans - TIP "Hydrostatic Test Pressure" with all its restrictions and mapping to templates preserved. Example of template instances generated from this pattern are also the same as in http://www.15926.org/viewtopic.php?f=29&t=221 .
Suggested representation is only RDF, no attempt to use OWL semantics.
A small tsp ontology is developed for patterns. It includes for classes and two predicates:
tsp:TemplateSignaturePattern – the class to hold patterns.
tsp:TSPRole – the class to hold pattern roles.
tsp:TSPVariable – the class to hold dummy entities representing pattern roles and internal variables (Scolem constants).
tsp:TSPMapping – the class to hold entities representing pattern mappings (template axioms).
tsp:TSPPart – the class to hold subjects which constitute building blocks for pattern mapping, template instances for example.
tsp:hasRole – relation from pattern (domain tsp:TemplateSignaturePattern) to its roles (range tsp:TSPRole).
tsp:hasPattern – relation from mapping (domain tsp:TSPMapping) to the pattern it represents (range tsp:TemplateSignaturePattern).
The entities comprising pattern definition (subjects and predicates) are put in ptrn: namespace. All dummy entities have human readable URIs to ease understanding of a pattern structure.
Full example:
Code: Select all
@prefix rdl: <http://posccaesar.org/rdl/>.
@prefix tpl: <http://data.posccaesar.org/tpl/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix owl: <http://www.w3.org/2002/07/owl#>.
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
@prefix ptrn: <http://data.posccaesar.org/ptrn/>.
@prefix dm: <http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003#>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix tsp: <http://data.posccaesar.org/tsp/>.
ptrn:hasPosessor a tsp:TSPRole.
ptrn:hasPressure a tsp:TSPRole.
ptrn:HydrostaticTestPressurePattern a tsp:TemplateSignaturePattern;
tsp:hasRole (ptrn:hasPosessor, ptrn:hasPressure).
ptrn:HydrostaticTestPressure_mapping1 a tsp:TSPMapping;
tsp:hasPattern ptrn:HydrostaticTestPressure;
ptrn:hasPosessor ptrn:HydrostaticTestPressure_possessor;
ptrn:hasPressure ptrn:HydrostaticTestPressure_value;
tsp:hasPart ptrn:HydrostaticTestPressure_entity1;
tsp:hasPart ptrn:HydrostaticTestPressure_entity2;
tsp:hasPart ptrn:HydrostaticTestPressure_entity3.
ptrn:HydrostaticTest_activity a tsp:TSPVariable;
rdfs:subClassOf rdl:RDS9706787. # HYDROSTATIC TESTING
ptrn:HydrostaticTestPressure_possessor a tsp:TSPVariable;
rdfs:subClassOf rdl:RDS430694. # PRESSURE-RATED ARTEFACT
ptrn:HydrostaticTest_fluid a tsp:TSPVariable;
rdfs:subClassOf rdl:RDS5605044 . # UNION OF ALLOWABLE TEST FLUIDS (faked ID)
ptrn:HydrostaticTestPressure_value a tsp:TSPVariable;
a ""^^xsd:float.
ptrn:HydrostaticTestPressure_entity1 a tsp:TSPPart;
a tpl:ClassOfParticipationDefinition ;
tpl:hasActivityType ptrn:HydrostaticTest_activity;
tpl:hasParticipantType ptrn:HydrostaticTestPressure_possessor ;
tpl:hasParticipantRole rdl:RDS4398439 ; # TESTED
tpl:hasCardinalityOfActivity rdl:RDS4367382 ; # ZERO-TO-INF (faked ID)
tpl:hasCardinalityOfParticipant rdl:RDS2387482 . # EXACTLY ONE (faked ID)
ptrn:HydrostaticTestPressure_entity2 a tsp:TSPPart ;
a tpl:ClassOfParticipationDefinition ;
tpl:hasActivityType ptrn:HydrostaticTest_activity;
tpl:hasParticipantType ptrn:HydrostaticTest_fluid ;
tpl:hasParticipantRole rdl:RDS13108820 ; # TEST FLUID
tpl:hasCardinalityOfActivity rdl:RDS4367382 ; # ZERO-TO-INF (faked ID)
tpl:hasCardinalityOfParticipant rdl:RDS2387482 . # EXACTLY ONE (faked ID)
ptrn:HydrostaticTestPressure_entity3 a tsp:TSPPart ;
a tpl:ClassOfIndividualHasIndirectPropertyWithValue ;
tpl:hasPossessorType ptrn:HydrostaticTest_fluid ;
tpl:hasIndirectPropertyType rdl:RDS361349 ; # HYDROSTATIC TEST PRESSURE
tpl:valPropertyValue ptrn:HydrostaticTestPressure_value ;
tpl:hasScale rdl:RDS4398739 . # TEST PRESSURE SCALES (a union of scales allowable in this context)
Two roles of the pattern. Notice that each and every TIP in TIPManager representation has explicit hasPossessor role which is absent from the interface, and its restriction is given by the Commodity class.ptrn:hasPosessor a tsp:TSPRole.
ptrn:hasPressure a tsp:TSPRole.
The pattern itself declared with two rolesptrn:HydrostaticTestPressurePattern a tsp:TemplateSignaturePattern;
tsp:hasRole (ptrn:hasPosessor, ptrn:hasPressure).
One particular mapping declared for the pattern.ptrn:HydrostaticTestPressure_mapping1 a tsp:TSPMapping;
tsp:hasPattern ptrn:HydrostaticTestPressure;
Dummy entities which will occupy pattern roles are introduced.ptrn:hasPosessor ptrn:HydrostaticTestPressure_possessor;
ptrn:hasPressure ptrn:HydrostaticTestPressure_value;
This mapping will consist of three parts as described below.tsp:hasPart ptrn:HydrostaticTestPressure_entity1;
tsp:hasPart ptrn:HydrostaticTestPressure_entity2;
tsp:hasPart ptrn:HydrostaticTestPressure_entity3.
Restrictions are defined for dummy entities representing pattern roles and internal variables (Scolem constants) which will be linking together entities comprising the mapping. Notice that some restrictions here are given by specializations (rdfs:subClassOf) as templates used in the mapping are class templates and roles are occupied by classes. If pattern is designed for individuals – restrictions will be given as classifications (a or rdf:type).ptrn:HydrostaticTest_activity a tsp:TSPVariable;
rdfs:subClassOf rdl:RDS9706787 . # HYDROSTATIC TESTING
ptrn:HydrostaticTestPressure_possessor a tsp:TSPVariable;
rdfs:subClassOf rdl:RDS430694 . # PRESSURE-RATED ARTEFACT
ptrn:HydrostaticTest_fluid a tsp:TSPVariable;
rdfs:subClassOf rdl:RDS5605044 . # UNION OF ALLOWABLE TEST FLUIDS (faked ID)
ptrn:HydrostaticTestPressure_value a tsp:TSPVariable;
a ""^^xsd:float .
The first template instance in the mapping.ptrn:HydrostaticTestPressure_entity1 a tsp:TSPPart ;
a tpl:ClassOfParticipationDefinition ;
This role is occupied by a dummy entity – internal variable (Scolem) representing an activity.tpl:hasActivityType ptrn:HydrostaticTest_activity;
This role is occupied by a dummy entity from a pattern role.tpl:hasParticipantType ptrn:HydrostaticTestPressure_possessor ;
These roles of a template have fixed RDL entities for values in this particular mapping.tpl:hasParticipantRole rdl:RDS4398439 ; # TESTED
tpl:hasCardinalityOfActivity rdl:RDS4367382 ; # ZERO-TO-INF (faked ID)
tpl:hasCardinalityOfParticipant rdl:RDS2387482 . # EXACTLY ONE (faked ID)
The second template instance in the mapping.ptrn:HydrostaticTestPressure_entity2 a tsp:TSPPart ;
a tpl:ClassOfParticipationDefinition ;
This role is occupied by a dummy entity – internal variable (Scolem). It is an explicit statement that here the activity is the same as in the previous template.tpl:hasActivityType ptrn:HydrostaticTest_activity;
This role is occupied by a new dummy entity – internal variable (Scolem) representing a test fluid.tpl:hasParticipantType ptrn:HydrostaticTest_fluid ;
These roles of a template have fixed RDL entities for values in this particular mapping.tpl:hasParticipantRole rdl:RDS13108820 ; # TEST FLUID
tpl:hasCardinalityOfActivity rdl:RDS4367382 ; # ZERO-TO-INF (faked ID)
tpl:hasCardinalityOfParticipant rdl:RDS2387482 . # EXACTLY ONE (faked ID)
The third template instance in the mapping.ptrn:HydrostaticTestPressure_entity3 a tsp:TSPPart ;
a tpl:ClassOfIndividualHasIndirectPropertyWithValue ;
This role is occupied by a dummy entity – internal variable (Scolem). It is an explicit statement that here the test fluid is the same as in the previous template.tpl:hasPossessorType ptrn:HydrostaticTest_fluid ;
This role is occupied by a dummy entity from a pattern role.tpl:valPropertyValue ptrn:HydrostaticTestPressure_value ;
These roles of a template have fixed RDL entities for values in this particular mapping.tpl:hasIndirectPropertyType rdl:RDS361349 ; # HYDROSTATIC TEST PRESSURE
tpl:hasScale rdl:RDS4398739 . # TEST PRESSURE SCALES (a union of scales allowable in this context) (faked ID)
Obviously the same method can be used to represent template axioms. Transformation from FOL can be easily automated.
I hope someone will read to this point and give his opinion below.