RDF Representation of Patterns

Post Reply
Message
Author
vvagr
Posts: 282
Joined: Mon Feb 27, 2012 11:01 pm
Location: Moscow, Russia
Contact:

RDF Representation of Patterns

#1 Post by vvagr »

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:

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) 
Comments:
ptrn:hasPosessor a tsp:TSPRole.
ptrn:hasPressure a tsp:TSPRole.
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:HydrostaticTestPressurePattern a tsp:TemplateSignaturePattern;
tsp:hasRole (ptrn:hasPosessor, ptrn:hasPressure).
The pattern itself declared with two roles
ptrn:HydrostaticTestPressure_mapping1 a tsp:TSPMapping;
tsp:hasPattern ptrn:HydrostaticTestPressure;
One particular mapping declared for the pattern.
ptrn:hasPosessor ptrn:HydrostaticTestPressure_possessor;
ptrn:hasPressure ptrn:HydrostaticTestPressure_value;
Dummy entities which will occupy pattern roles are introduced.
tsp:hasPart ptrn:HydrostaticTestPressure_entity1;
tsp:hasPart ptrn:HydrostaticTestPressure_entity2;
tsp:hasPart ptrn:HydrostaticTestPressure_entity3.
This mapping will consist of three parts as described below.
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 .
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:HydrostaticTestPressure_entity1 a tsp:TSPPart ;
a tpl:ClassOfParticipationDefinition ;
The first template instance in the mapping.
tpl:hasActivityType ptrn:HydrostaticTest_activity;
This role is occupied by a dummy entity – internal variable (Scolem) representing an activity.
tpl:hasParticipantType ptrn:HydrostaticTestPressure_possessor ;
This role is occupied by a dummy entity from a pattern role.
tpl:hasParticipantRole rdl:RDS4398439 ; # TESTED
tpl:hasCardinalityOfActivity rdl:RDS4367382 ; # ZERO-TO-INF (faked ID)
tpl:hasCardinalityOfParticipant rdl:RDS2387482 . # EXACTLY ONE (faked ID)
These roles of a template have fixed RDL entities for values in this particular mapping.
ptrn:HydrostaticTestPressure_entity2 a tsp:TSPPart ;
a tpl:ClassOfParticipationDefinition ;
The second template instance in the mapping.
tpl:hasActivityType ptrn:HydrostaticTest_activity;
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:hasParticipantType ptrn:HydrostaticTest_fluid ;
This role is occupied by a new dummy entity – internal variable (Scolem) representing a test fluid.
tpl:hasParticipantRole rdl:RDS13108820 ; # TEST FLUID
tpl:hasCardinalityOfActivity rdl:RDS4367382 ; # ZERO-TO-INF (faked ID)
tpl:hasCardinalityOfParticipant rdl:RDS2387482 . # EXACTLY ONE (faked ID)
These roles of a template have fixed RDL entities for values in this particular mapping.
ptrn:HydrostaticTestPressure_entity3 a tsp:TSPPart ;
a tpl:ClassOfIndividualHasIndirectPropertyWithValue ;
The third template instance in the mapping.
tpl:hasPossessorType ptrn:HydrostaticTest_fluid ;
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:valPropertyValue ptrn:HydrostaticTestPressure_value ;
This role is occupied by a dummy entity from a pattern role.
tpl:hasIndirectPropertyType rdl:RDS361349 ; # HYDROSTATIC TEST PRESSURE
tpl:hasScale rdl:RDS4398739 . # TEST PRESSURE SCALES (a union of scales allowable in this context) (faked ID)
These roles of a template have fixed RDL entities for values in this particular mapping.

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.
Last edited by vvagr on Tue Jun 03, 2014 2:10 pm, edited 1 time in total.

vvagr
Posts: 282
Joined: Mon Feb 27, 2012 11:01 pm
Location: Moscow, Russia
Contact:

Re: RDF Representation of Patterns

#2 Post by vvagr »

The proposal slightly changed - a class tsp:TSPVariable is introduced in the model and all dummy entities representing pattern roles and internal variables are classified with it. This classification allows to identify napped roles of patterns more effectively.

HansTeijgeler
Posts: 283
Joined: Sun Jan 22, 2012 10:02 pm

Re: RDF Representation of Patterns

#3 Post by HansTeijgeler »

@Victor - At first sight it looks good, although I haven't digested it completely yet. Could you complete this with the full code for that tsp ontology? Also include TSPPattern and TSPMappingGraph (were not on the list).

Since this code is for the mapping, where do you store it? Amidst the lifecycle information? How easy will it be to retrieve the link between the pattern and its constituting templates? What if one data element changes (e.g. the valPropertyValue), what happens to the unchanged other templates?

vvagr
Posts: 282
Joined: Mon Feb 27, 2012 11:01 pm
Location: Moscow, Russia
Contact:

Re: RDF Representation of Patterns

#4 Post by vvagr »

Hans,

I'm sorry, I've used an older version of an example. Now it is corrected

TSPPattern became TemplateSignaturePattern
TSPMappingGraph became TSPMapping (I was considering an option to put each mapping in a separate named graph, probable will do it anyway)

I do not yet have a full code for tsp ontology. Not many facts to put in really, domain and range for properties are indicated already. As it is a meta-level ontology, I do not think it will be necessary to connect it to Part2. On the other hand, it is possible to link it to p7tm or even make it part of p7tm - if people agree that it can be a good way to record template axioms.

Post Reply