Structures for the publication of TIPs

Message
Author
Andrew.Prosser

Structures for the publication of TIPs

#1 Post by Andrew.Prosser »

Please post ideas/discussion relating to the publication of TIPs in this topic. The initial suggestion is to publish TIPs (Template Information Patterns) using the same structures as TSPs (Template Signature Patterns) but with the mapping between TIPs and TSPs expressed. The mappings may be expressed using structures from iRingTools mappings or using any other suitable technique as agreed in the Part 8 implementation group

base really draft example to get discussion going, this is posted as a structural example please don't take it as a working proposal :

Code: Select all


<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rdf:RDF [
	<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
	<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
	<!ENTITY owl "http://www.w3.org/2002/07/owl#" >
	<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
	<!ENTITY tips "http://www.iring.org/TIPS#" >
	<!ENTITY skos "http://www.w3.org/2004/02/skos/core#" >
	<!ENTITY rdl "http://posccaesar.org/rdl/" >
	<!ENTITY tpl "http://tpl.rdlfacade.org/data#" >
	<!ENTITY p7tpl "http://standards.iso.org/iso/ts/15926/-8/ed-1/tech/reference-data/p7tpl#" >
	<!ENTITY p7tm "http://standards.iso.org/iso/ts/15926/-8/ed-1/tech/reference-data/template-model#">
	<!ENTITY dm "http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003#">
]>
<rdf:RDF xmlns:rdf="&rdf;" xmlns:p7tm="&p7tm;" xmlns:rdfs="&rdfs;" xmlns:tips="&tips;" xmlns:skos="&skos;" xmlns:rdl="&rdl;" xmlns:tpl="&tpl;" xmlns:owl="&owl;">

	<!-- =========================================================
	     self contained example 
	     ========================================================= -->
	<tips:TemplateInformationPattern rdf:about="#385">
		<rdfs:label>Atmospheric Pressure</rdfs:label>
		<rdfs:comment>A pressure that is representing the weight of the air column standing vertically over the place where the measurement is done??</rdfs:comment>
				
		<!-- standard metadata fields ... -->
		<tips:id>385</tips:id>
		<tips:guid>q4r415-3243-3243-32413</tips:guid>
		<tips:status>Complete</tips:status>
		<skos:note>some notes about use??</skos:note>
		<skos:note>some more notes about use??</skos:note>
		<skos:editorialNote>some notes to the editors??</skos:editorialNote>

		<!-- how should we represent expected context for this TIP??  
		This is commodity but made more useful by allowing more specific and generic classes to be used -->
		<tips:expectedContext rdf:resource="&rdl;?????"/>
		<tips:expectedContext rdf:resource="&rdl;?????"/>

		<!-- Do we need classification for TIPS, beyond context??-->
		<rdf:type rdf:resource="&rdl;?????"/>

		<!-- Required properties for the TIP -->
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty>
					<owl:ObjectProperty rdf:about="#385Individual">
						<rdf:type rdf:resource="&tips;TIPRole"/>
						<rdfs:label>An individual with an Atmospheric Pressure measurement associated to it</rdfs:label>
						<rdfs:range rdf:resource="&dm;PossibleIndividual"/>
						<tips:exampleValue rdf:resource="http:www.example.com#myThing"/>
					</owl:ObjectProperty>
				</owl:onProperty>
				<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
			</owl:Restriction>
		</rdfs:subClassOf>
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty>
					<owl:DatatypeProperty rdf:about="#385PressureValue">
						<rdf:type rdf:resource="&tips;TIPRole"/>
						<rdfs:label>A pressure value</rdfs:label>
						<rdfs:range rdf:resource="&xsd;float"/>
						<tips:exampleValue rdf:datatype="&xsd;float">20.0</tips:exampleValue>
					</owl:DatatypeProperty>
				</owl:onProperty>
				<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
			</owl:Restriction>			
		</rdfs:subClassOf>
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty>
					<owl:ObjectProperty rdf:about="#385PressureScale">
						<rdf:type rdf:resource="&tips;TIPRole"/>
						<rdfs:label>A Pressure Scale</rdfs:label>
						<rdfs:range rdf:resource="&rdl;RDS1359461141"/><!-- Pressure Scale Class constraint-->
						<tips:exampleValue rdf:resource="&rdl;R98787754267" /><!--Pascal -->
					</owl:ObjectProperty>
				</owl:onProperty>
				<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
			</owl:Restriction>			
		</rdfs:subClassOf>
		
		<!-- mappings -->
		<tips:templateMappings rdf:parseType="Collection">
			<tips:TemplateMap rdf:about="#385_TemplateMap_1">
				<tips:hasTemplateInformationPattern rdf:resource="#385"/>
				<tips:hasTemplate rdf:resource="&tpl;R26101158400" />
				<tips:roleMappings rdf:parseType="Collection">
					<tips:TemplateRoleMap rdf:about="#385_TemplateMap_1_1">
						<tips:hasRole rdf:resource="&tpl;R59896853239" />
						<tips:hasValue rdf:resource="&rdl;R11440551409" />
					</tips:TemplateRoleMap>
					<tips:TemplateRoleMap rdf:about="#385_TemplateMap_1_2">
						<tips:hasRole rdf:resource="&tpl;R16314127825" />
						<tips:hasProperty rdf:resource="#385Individual" />
					</tips:TemplateRoleMap>
					<tips:TemplateRoleMap  rdf:about="#385_TemplateMap_1_3">
						<tips:hasRole rdf:resource="&tpl;R90688063648" />
						<tips:hasProperty rdf:resource="#385PressureValue" />
					</tips:TemplateRoleMap>
					<tips:TemplateRoleMap  rdf:about="#385_TemplateMap_1_4">
						<tips:hasRole rdf:resource="&tpl;R93884193692" />
						<tips:hasPoperty rdf:resource="#385PressureScale" />
					</tips:TemplateRoleMap>
				</tips:roleMappings>
			</tips:TemplateMap>
			<!-- TemplateMap .... as required -->
		</tips:templateMappings>
	</tips:TemplateInformationPattern>
		
	
	<!-- ==================================================
	     separated out example, same RDF structure/meaning 
		 ================================================== -->
	
	<!-- roles/properties for tip-->
	<owl:ObjectProperty rdf:about="#385_v2_Individual">
		<rdf:type rdf:resource="&tips;TIPRole"/>
		<rdfs:label>An individual with an Atmospheric Pressure measurement associated to it</rdfs:label>
		<rdfs:range rdf:resource="&dm;PossibleIndividual"/>
		<tips:exampleValue rdf:resource="http:www.example.com#myThing"/>
	</owl:ObjectProperty>
	<owl:DatatypeProperty rdf:about="#385_v2_PressureValue">
		<rdf:type rdf:resource="&tips;TIPRole"/>
		<rdfs:label>A pressure value</rdfs:label>
		<rdfs:range rdf:resource="&xsd;float"/>
		<tips:exampleValue rdf:datatype="&xsd;float">20.0</tips:exampleValue>
	</owl:DatatypeProperty>
	<owl:ObjectProperty rdf:about="#385_v2_PressureScale">
		<rdf:type rdf:resource="&tips;TIPRole"/>
		<rdfs:label>A Pressure Scale</rdfs:label>
		<rdfs:range rdf:resource="&rdl;RDS1359461141"/><!-- Pressure Scale Class constraint-->
		<tips:exampleValue rdf:resource="&rdl;R98787754267" /><!--Pascal -->
	</owl:ObjectProperty>
	
	<!-- tip definition -->
	<tips:TemplateInformationPattern rdf:about="#385_v2">
		<rdfs:label>Atmospheric Pressure</rdfs:label>
		<rdfs:comment>A pressure that is representing the weight of the air column standing vertically over the place where the measurement is done??</rdfs:comment>

		<!-- standard metadata fields ... -->
		<tips:id>385</tips:id>
		<tips:guid>q4r415-3243-3243-32413</tips:guid>
		<tips:status>Complete</tips:status>
		<skos:note>some notes about use??</skos:note>
		<skos:note>some more notes about use??</skos:note>
		<skos:editorialNote>some notes to the editors??</skos:editorialNote>

		<!-- how should we represent expected context for this TIP??  
		This is commodity but made more useful by allowing more specific and generic classes to be used -->
		<tips:expectedContext rdf:resource="&rdl;?????"/>
		<tips:expectedContext rdf:resource="&rdl;?????"/>

		<!-- Do we need classification for TIPS, beyond context??-->
		<rdf:type rdf:resource="&rdl;?????"/>

		<!-- Required properties for the TIP -->
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty rdf:resource="#385_v2_Individual"/>
				<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
			</owl:Restriction>
		</rdfs:subClassOf>
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty rdf:Resource="#385_v2_PressureValue"/>
				<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
			</owl:Restriction>
		</rdfs:subClassOf>
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty rdf:resource="#385_v2_PressureScale"/>
				<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
			</owl:Restriction>
		</rdfs:subClassOf>

		<!-- mappings -->
		<tips:templateMappings rdf:parseType="Collection">
			<tips:TemplateMap rdf:resource="#385_v2_TemplateMap_1"/>
		</tips:templateMappings>
	</tips:TemplateInformationPattern>
	
	<!-- template mapping -->
	<tips:TemplateMap rdf:about="#385_v2_TemplateMap_1">
		<tips:hasTemplateInformationPattern rdf:resource="#385"/>
		<tips:hasTemplate rdf:resource="&tpl;R26101158400" />
		<tips:roleMappings rdf:parseType="Collection">
			<tips:TemplateRoleMap rdf:resource="#385_v2_TemplateMap_1_1"/>
			<tips:TemplateRoleMap rdf:resource="#385_v2_TemplateMap_1_2"/>
			<tips:TemplateRoleMap rdf:resource="#385_v2_TemplateMap_1_3"/>
			<tips:TemplateRoleMap rdf:resource="#385_v2_TemplateMap_1_4"/>
		</tips:roleMappings>
	</tips:TemplateMap>
	
	<!-- template role mappings -->
	<tips:TemplateRoleMap rdf:about="#385_v2_TemplateMap_1_1">
		<tips:hasRole rdf:resource="&tpl;R59896853239" />
		<tips:hasValue rdf:resource="&rdl;R11440551409" />
	</tips:TemplateRoleMap>
	<tips:TemplateRoleMap rdf:about="#385_v2_TemplateMap_1_2">
		<tips:hasRole rdf:resource="&tpl;R16314127825" />
		<tips:hasProperty rdf:resource="#385Individual" />
	</tips:TemplateRoleMap>
	<tips:TemplateRoleMap  rdf:about="#385_v2_TemplateMap_1_3">
		<tips:hasRole rdf:resource="&tpl;R90688063648" />
		<tips:hasProperty rdf:resource="#385PressureValue" />
	</tips:TemplateRoleMap>
	<tips:TemplateRoleMap  rdf:about="#385_v2_TemplateMap_1_4">
		<tips:hasRole rdf:resource="&tpl;R93884193692" />
		<tips:hasPoperty rdf:resource="#385PressureScale" />
	</tips:TemplateRoleMap>
	
	<!-- ======================================================
	     Thoughts
		 ======================================================
		 
		 - I've removed the Template description pattern to use OWL as normally used.
		 - I've used rdfs:range instead of restrictions on the pattern since this is in line with use and simpler to parse
		 - I've renamed relations to be has....   val.... as per normal template practice
		 - Collections could be replaced with multiple predicates or some other form to make SPARQL access easier.
		 - There is potential for the properties to be reused between TIPs.  Such as common properties like pressureScale, Individual etc.
		 
		 -->
</rdf:RDF>
Last edited by Andrew.Prosser on Fri Jun 14, 2013 2:21 pm, edited 2 times in total.

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

Re: Structures for the publication of TIPs

#2 Post by vvagr »

Some requirements for pattern description/representation and for pattern mapping to templates/other constructs:

1. Role optionality.

Pattern roles can be optional. For example, Definition pattern has roles: hasObject, hasDefinition, hasLanguage, hasContext. Two first roles are mandatory, second two roles are optional.

Probable this can be done in P8 template format suggested by Andrew above, relaxing owl:qualifiedCardinality? I don't know enough of OWL for that.

2. Multiple realizations.

Pattern can be mapped to templates in more then one way. For example, Definition pattern can be expanded as p7tpl:Definition template, rdswip:DefinitionTemplate, p8iwg:DefinitionOfAnInformationRepresentatione, part2:Definition and part2:ClassOfDefinition

We need an ability to describe several mapping options and refer to a particular option to use.

3. Realization by predicates.

Pattern can be mapped not only to template(s), but directly to RDF predicate. For example, Definition pattern can be directly realised as hasDefinition data property. Or rdf:label - it is obviously a way to realize Identification pattern.

4. Multiple linked roles.

If a pattern is realised by two or more templates, we need an ability to specify in mapping which roles are occupied by the same entities. As well as I can understand, currently Graph Mapping used in iRINGTools (both in Adapter Manager and in new TIP Editor) allows for only one linked pair of roles in template chain. It is probable enough for IIP patterns which are essentially binary relations. But complex pattern mapping to templates may require more linked roles pairs, just like a complex template has more then one Scolem term in its axiom.

Item 1 above is about representation of pattern signature. Items 2 to 4 are about mapping of pattern to templates (and predicates). For this P8 can not give us any clues, as it gives us no clues about representation of template axiom.

This set of requirements is realised in the pattern engine of our .15926 Editor, but not in RDF. We've used format of Python dictionary for internal representation of patterns. It is fully documented, relevant part can be separately downloaded below:
15926EditorDocOnPatterns.rar
(16.64 KiB) Downloaded 846 times

Andrew.Prosser

Re: Structures for the publication of TIPs

#3 Post by Andrew.Prosser »

Thanks Victor a partial response below till I can access your rar file...

What pattern are you referring to, ID please?? I can't find a Definition pattern in the TIPs db.

1. Optional Roles

- Optional Roles can be expressed using minCardinality and maxCardinality constraints. There are qualified and unqualified variants.

- I haven't been in on any discussion on optional roles and am concerned they might better be expressed as separate TIPs otherwise the same pattern can be used for several different meanings which will make implementation harder or more error prone. Overloaded patterns could be useful but distinct ensuring common meaning.

2. Multiple Realizations

- If multiple realizations are required (1 is hard enough to define and maintain) this can be handled in several ways.
a.Classification of TemplateMap resources
b.Software interpreting the referenced templates
c.Separate mapping collections for each realization.

- Personally I'd prefer to see separate mapping collections so that no-one is in any doubt what mappings are relevant to a single realization though this could be combined with classification.

- Again I've never heard this discussed and see no evidence of it in the TIPs tools. Part 2 mappings are the responsibility of templates not TIPs. TIPs was supposed to bring clarity so that there were excepted best practices for expansion to templates that everyone has access to so the use of several different template expansions seems to muddy the clarity provided.

3. Realization by predicates

- Again TIPs is patterns of template usage. Part 8 allows some limited abbreviation of template structures using rdf predicates but it doesn't mean that the template is not the modelling item that we are mapping to. In my opinion we should map TIPS to templates and the encoding syntax of those templates (template->predicate) is not the responsibility of TIPs but is the responsibility of Part 8 software.

4. Multiple Linked Roles

- Using the structure presented you can have several TemplateMap instances for a TIP and each TemplateRoleMap is independent allowing it to reference any property/Role that it needs. This allows the Properties/Roles of a TIP to be shared by several TemplateRoleMaps. I'll post a separate example to demonstrate that.

thanks again
Andy

hmottestad
Posts: 18
Joined: Mon May 06, 2013 6:54 am

Re: Structures for the publication of TIPs

#4 Post by hmottestad »

I'm thinking optional should be a universal restriction. ie something like this (Manchester syntax)

hasDescription ONLY string

This way we can read the OWL file and figure out which attributes are optional. If something is optional but without a required type (ie. not qualified).

hasDescription ONLY Thing (owl:Thing)

However this is technically useless since any ontology entails hasDescription ONLY Thing. Although it can be used for figuring out which attributes are optional and untyped.

Since RDF is not strict on the schema the same way that SQL is, you can still add any attribute you want.
Håvard Mikkelsen Ottestad @ PCA

Andrew.Prosser

Re: Structures for the publication of TIPs

#5 Post by Andrew.Prosser »

optional property declaration....

<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#optionalProperty"/>
<owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">
0
</owl:minCardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#optionalProperty"/>
<owl:maxCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">
1
</owl:maxCardinality>
</owl:Restriction>
</rdfs:subClassOf>

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

Re: Structures for the publication of TIPs

#6 Post by vvagr »

Andrew,
What pattern are you referring to, ID please?? I can't find a Definition pattern in the TIPs db.
Sorry for confusion. I'm talking more about TSPs now, which are more general then TIPs. Definition TSP is mentioned in JORD Mapping methodology and will be specified there. Bottom-up approach of TIPs and top-down approach of TSPs should be brought together. Some requirements arise out of this top-down approach and that's probable why they never appeared in TIPs discussions of IIP.
I haven't been in on any discussion on optional roles and am concerned they might better be expressed as separate TIPs otherwise the same pattern can be used for several different meanings which will make implementation harder or more error prone.
I hope that will be resolved by this TSPs-TIPs approach. General TSPs with optional roles and very general role restrictions, TIPs as specializations of TSPs with role sets fixed and roles appropriately restricted.
Personally I'd prefer to see separate mapping collections
Agreed.
Part 2 mappings are the responsibility of templates not TIPs.
the encoding syntax of those templates (template->predicate) is not the responsibility of TIPs
Yes and no :-) TIP realization by templates is very similar to template realization by Part 2 entities (its axiom). As we've no standard way to record an axiom yet - I'd like to investigate possibility for a uniform representation for these constructs.
Part 8 allows some limited abbreviation of template structures using rdf predicates
When I'm mentioning realization by predicates - I have in mind "P12"/Native OWL plans, not limited use of predicates in P8. As far as I know - representation by predicates is recognised and developed in many projects. Mapping to predicates will be necessary at some point. I'm investigating this approach in my Editor - you can search for pattern, find a pattern realized by predicates, and create the same pattern using its mapping to templates.

As template roles are also predicates - I don't think mapping to predicates will be much different to mapping to template roles?

Thank you for an example with cardinalities. Please provide an example of pattern mapped to several templates with linked roles.

Andrew.Prosser

Re: Structures for the publication of TIPs

#7 Post by Andrew.Prosser »

Ok so I need to get up to speed on the optional/ null roles discussion for TSPs. My understanding is at the moment that null and optional roles would require a different expansion. I'm not sure whether a single TIP should provide consistent semantics and have relationships to TIPs that support null/optional variants or whether the mappings need to be enriched enough to cater for mapping variants for null and optional roles. I'd like to keep things simple and have consistent semantics per TIP definition, with simpler mapping structures and relations to overloaded variants though I understand this may complicate TIP usage.

In concept TIPs and TSPs are performing the same job but both are in very different contexts. Lets not talk about TIPs being specialisations of TSPs since then we get confused with specialised templates. TIP definitions and TSPs could be patterns forms with a common ancestor but in my opinion one shouldn't be a specialisation of the other otherwise our 'context' gets confused.

We could consider how the mapping structures for TIPs and TSPs could be shared to allow their use for mapping to part 2. Its not clear to me whether TSPs should be mapping to full Part 2 forms or mapping to axioms that need further expansion. We can make the TIP mapping terms more general for use but someone else will have to validate how they can be used for TSP expansion since my understanding of Axiom notation is limited.

Here's a multiple template example though I haven't got all the template ids populated....

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rdf:RDF [
	<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
	<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
	<!ENTITY owl "http://www.w3.org/2002/07/owl#" >
	<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
	<!ENTITY tips "http://www.iring.org/TIPS#" >
	<!ENTITY skos "http://www.w3.org/2004/02/skos/core#" >
	<!ENTITY rdl "http://posccaesar.org/rdl/" >
	<!ENTITY tpl "http://tpl.rdlfacade.org/data#" >
	<!ENTITY p7tpl "http://standards.iso.org/iso/ts/15926/-8/ed-1/tech/reference-data/p7tpl#" >
	<!ENTITY p7tm "http://standards.iso.org/iso/ts/15926/-8/ed-1/tech/reference-data/template-model#">
	<!ENTITY dm "http://rds.posccaesar.org/2008/02/OWL/ISO-15926-2_2003#">
]>
<rdf:RDF xmlns:rdf="&rdf;" xmlns:p7tm="&p7tm;" xmlns:rdfs="&rdfs;" xmlns:tips="&tips;" xmlns:skos="&skos;" xmlns:rdl="&rdl;" xmlns:tpl="&tpl;" xmlns:owl="&owl;">

	<!-- =========================================================
	     ImpellerDiameter
	     ========================================================= -->
	<tips:TemplateInformationPattern rdf:about="#DEXPIImpellerDiameter">
		<rdfs:label>DEXPI Impeller Diameter</rdfs:label>
		<rdfs:comment>The diameter of the impeller on a Centrifugal Pump</rdfs:comment>
				
		<!-- standard metadata fields ... -->
		<tips:id>DEXPI_1</tips:id>
		<tips:guid>5365-563-6536-256256</tips:guid>
		<tips:status>Draft</tips:status>

		<!-- how should we represent expected context for this TIP??  
		This is commodity but made more useful by allowing more specific and generic classes to be used -->
		<!-- Centrifugal Pump -->
		<tips:expectedContext rdf:resource="&rdl;RDS416834"/>

		<!-- Do we need classification for TIPS, beyond context??-->
		<rdf:type rdf:resource="&rdl;?????"/>

		<!-- Required properties for the TIP -->
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty>
					<owl:ObjectProperty rdf:about="#22CentrifugalPumpIndividual">
						<rdf:type rdf:resource="&tips;TIPRole"/>
						<rdfs:label>The Centrifugal Pump the impeller is on</rdfs:label>
						<rdfs:range rdf:resource="&rdl;RDS416834"/>
						<tips:exampleValue rdf:resource="http://www.example.com#P101"/>
					</owl:ObjectProperty>
				</owl:onProperty>
				<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
			</owl:Restriction>
		</rdfs:subClassOf>
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty>
					<owl:ObjectProperty rdf:about="#22ImpellerIndividual">
						<rdf:type rdf:resource="&tips;TIPRole"/>
						<rdfs:label>The identity of the Impeller (must be generated since not maintained)</rdfs:label>
						<rdfs:range rdf:resource="&rdl;RDS245789"/>
						<tips:exampleValue rdf:resource="http://www.example.com#P101_Impeller"/>
					</owl:ObjectProperty>
				</owl:onProperty>
				<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
			</owl:Restriction>
		</rdfs:subClassOf>
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty>
					<owl:DatatypeProperty rdf:about="#22LengthValue">
						<rdf:type rdf:resource="&tips;TIPRole"/>
						<rdfs:label>A linear value</rdfs:label>
						<rdfs:range rdf:resource="&xsd;float"/>
						<tips:exampleValue rdf:datatype="&xsd;float">20.0</tips:exampleValue>
					</owl:DatatypeProperty>
				</owl:onProperty>
				<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
			</owl:Restriction>			
		</rdfs:subClassOf>
		<rdfs:subClassOf>
			<owl:Restriction>
				<owl:onProperty>
					<owl:ObjectProperty rdf:about="#22LengthScale">
						<rdf:type rdf:resource="&tips;TIPRole"/>
						<rdfs:label>A linear Scale</rdfs:label>
						<rdfs:range rdf:resource="&rdl;RDS1355222971"/>
						<tips:exampleValue rdf:resource="&rdl;RDS1357739" />
					</owl:ObjectProperty>
				</owl:onProperty>
				<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>
			</owl:Restriction>			
		</rdfs:subClassOf>
		
		<!-- mappings -->
		<tips:templateMappings rdf:parseType="Collection">
			<!-- ClassificationOfIndividual -->
			<tips:TemplateMap rdf:about="#22_TemplateMap_1">
				<tips:hasTemplateInformationPattern rdf:resource="#22"/>
				<tips:hasTemplate rdf:resource="&tpl;R63638239485" />
				<tips:roleMappings rdf:parseType="Collection">
					<!-- hasIndividual-->
					<tips:TemplateRoleMap rdf:about="#22_TemplateMap_1_1">
						<tips:hasRole rdf:resource="&tpl;R44102076948" />
						<tips:hasProperty rdf:resource="#22CentrifugalPumpIndividual" />
					</tips:TemplateRoleMap>
					<!-- hasClass -->
					<tips:TemplateRoleMap rdf:about="#22_TemplateMap_1_2">
						<tips:hasRole rdf:resource="&tpl;R54167847248" />
						<tips:hasValue rdf:resource="&rdl;RDS416834" />
					</tips:TemplateRoleMap>
				</tips:roleMappings>
			</tips:TemplateMap>
			<!-- ClassifiedAssemblyOfIndividual -->
			<tips:TemplateMap rdf:about="#22_TemplateMap_2">
				<tips:hasTemplateInformationPattern rdf:resource="#22"/>
				<tips:hasTemplate rdf:resource="&tpl;???" />
				<tips:roleMappings rdf:parseType="Collection">
					<!-- hasAssemblyType-->
					<tips:TemplateRoleMap rdf:about="#22_TemplateMap_2_1">
						<tips:hasRole rdf:resource="&tpl;???" />
						<tips:hasProperty rdf:resource="&rdl;????" />
					</tips:TemplateRoleMap>
					<!-- hasPart-->
					<tips:TemplateRoleMap rdf:about="#22_TemplateMap_2_1">
						<tips:hasRole rdf:resource="&tpl;???" />
						<tips:hasProperty rdf:resource="#22CentrifugalPumpIndividual" />
					</tips:TemplateRoleMap>
					<!-- hasWhole -->
					<tips:TemplateRoleMap rdf:about="#22_TemplateMap_2_2">
						<tips:hasRole rdf:resource="&tpl;???" />
						<tips:hasProperty rdf:resource="#22ImpellerIndividual" />
					</tips:TemplateRoleMap>
				</tips:roleMappings>
			</tips:TemplateMap>
			<!-- ClassificationOfIndividual -->
			<tips:TemplateMap rdf:about="#22_TemplateMap_3">
				<tips:hasTemplateInformationPattern rdf:resource="#22"/>
				<tips:hasTemplate rdf:resource="&tpl;R63638239485" />
				<tips:roleMappings rdf:parseType="Collection">
					<!-- hasIndividual-->
					<tips:TemplateRoleMap rdf:about="#22_TemplateMap_3_1">
						<tips:hasRole rdf:resource="&tpl;R44102076948" />
						<tips:hasProperty rdf:resource="#22ImpellerIndividual" />
					</tips:TemplateRoleMap>
					<!-- hasClass -->
					<tips:TemplateRoleMap rdf:about="#22_TemplateMap_3_2">
						<tips:hasRole rdf:resource="&tpl;R54167847248" />
						<tips:hasValue rdf:resource="&rdl;RDS245789" />
					</tips:TemplateRoleMap>
				</tips:roleMappings>
			</tips:TemplateMap>
			<!-- IndirectPropertyScaleReal -->
			<tips:TemplateMap rdf:about="#22_TemplateMap_4">
				<tips:hasTemplateInformationPattern rdf:resource="#385"/>
				<tips:hasTemplate rdf:resource="&tpl;R26101158400" />
				<tips:roleMappings rdf:parseType="Collection">
					<tips:TemplateRoleMap rdf:about="#22_TemplateMap_4_1">
						<tips:hasRole rdf:resource="&tpl;R59896853239" />
						<tips:hasValue rdf:resource="&rdl;RDS350954" />
					</tips:TemplateRoleMap>
					<tips:TemplateRoleMap rdf:about="#22_TemplateMap_4_2">
						<tips:hasRole rdf:resource="&tpl;R16314127825" />
						<tips:hasProperty rdf:resource="#22ImpellerIndividual" />
					</tips:TemplateRoleMap>
					<tips:TemplateRoleMap  rdf:about="#22_TemplateMap_4_3">
						<tips:hasRole rdf:resource="&tpl;R90688063648" />
						<tips:hasProperty rdf:resource="#22LengthValue" />
					</tips:TemplateRoleMap>
					<tips:TemplateRoleMap  rdf:about="#22_TemplateMap_4_4">
						<tips:hasRole rdf:resource="&tpl;R93884193692" />
						<tips:hasPoperty rdf:resource="#22LengthScale" />
					</tips:TemplateRoleMap>
				</tips:roleMappings>
			</tips:TemplateMap>
		</tips:templateMappings>
	</tips:TemplateInformationPattern>
</rdf:RDF>

KeithWillshaw
Posts: 77
Joined: Tue May 15, 2012 8:48 am

Re: Structures for the publication of TIPs

#8 Post by KeithWillshaw »

vvagr wrote:Some requirements for pattern description/representation and for pattern mapping to templates/other constructs:

1. Role optionality.

Pattern roles can be optional. For example, Definition pattern has roles: hasObject, hasDefinition, hasLanguage, hasContext. Two first roles are mandatory, second two roles are optional.
As I understand it null values in Template roles are not permitted so an optional role would have to be handled using some convention
vvagr wrote: 2. Multiple realizations.

Pattern can be mapped to templates in more then one way. For example, Definition pattern can be expanded as p7tpl:Definition template, rdswip:DefinitionTemplate, p8iwg:DefinitionOfAnInformationRepresentatione, part2:Definition and part2:ClassOfDefinition

We need an ability to describe several mapping options and refer to a particular option to use.

3. Realization by predicates.

Pattern can be mapped not only to template(s), but directly to RDF predicate. For example, Definition pattern can be directly realised as hasDefinition data property. Or rdf:label - it is obviously a way to realize Identification pattern.
These sound like interesting ideas but I'l like to avoid this discussion getting sidetracked by them. Perhaps you should start a new thread for them ?
vvagr wrote: 4. Multiple linked roles.

If a pattern is realised by two or more templates, we need an ability to specify in mapping which roles are occupied by the same entities. As well as I can understand, currently Graph Mapping used in iRINGTools (both in Adapter Manager and in new TIP Editor) allows for only one linked pair of roles in template chain. It is probable enough for IIP patterns which are essentially binary relations. But complex pattern mapping to templates may require more linked roles pairs, just like a complex template has more then one Scolem term in its axiom.
There are some examples in Tip Editor where there is more than one linked pair of Template Roles

TIP 114 (Design Temperature Line) is an example
There is a link from the Line (PipingNetworkSystem) to the LineSegment (PipingNetworkStream) and from there to the FluidStream which is actually the Object with the Property ProcessDesignTemperature

Keith

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

Re: Structures for the publication of TIPs

#9 Post by vvagr »

Keith,
As I understand it null values in Template roles are not permitted so an optional role would have to be handled using some convention
Here I'm talking about optional roles in Template Signature Patterns. Templates are not allowed to have optional roles, which means that optional roles in patterns are possible only if there are multiple realizations of one TSP by different template graphs.

TIPs, if we consider them specializations of TSPs, probable should be defined unambiguously with all optionality excluded.
TIP 114 (Design Temperature Line) is an example
There is a link from the Line (PipingNetworkSystem) to the LineSegment (PipingNetworkStream) and from there to the FluidStream which is actually the Object with the Property ProcessDesignTemperature
As well as I understand this, here we have three templates in a chain, the first is connected to the second by one role, the second to the third by one role. This doesn't contradict a Graph Mapping methodology at all. I'll try to prepare an example of more complex situation.
These sound like interesting ideas but I'l like to avoid this discussion getting sidetracked by them. Perhaps you should start a new thread for them ?
It is an important question - whether we are discussing urgent RDF solution for TIPs only, or we are trying to define representation which will cover both TIPs and TSPs?

Andrew.Prosser

Re: Structures for the publication of TIPs

#10 Post by Andrew.Prosser »

Notes from todays discussion 20-06-13...... just working out how to attach a file....

Post Reply