This research describes an ontology design pattern for dynamically conceptualizing, establishing, tracking, and updating relative relationships and dependencies between entities (real or representational) of a physical, temporal, and/or importance scope. We present a Relative Relationship (RR) Pattern, associated axioms, an implementation of current geometric scale translation research, a detailed example, and suggestions for other potential use cases. It provides data hooks that allow dynamic updating of linked data as changes occur in preference systems, scaling systems, or time expiration parameters; additionally, it separates the false notion that level of detail is always synonymous with scope. Furthermore, we discuss how this design pattern potentially acts as an intermediate step to assist the transition between open linked-data and decision support frameworks that need to readily update changes within the accurate data over modern, distributed data access points.
Development of applications using Semantic Web1 principles has the potential
to enable integration of highly diverse and heterogeneous domains by creating
data that is as intelligent as possible. This is signi cant as applications need
increasing amounts of interdisciplinary data (such as resilience systems or
lifetime cost analysis) there is a need for computational and data abstractions that
can interconnect concepts and relate them across a variety of professional elds.
Additionally, there is a need for e ective methods of integrating dynamic,
discoverable, intelligent data sets2 into tools as they become available, preferably
in at least a semi-automated manner [
Development of the Green Scale3 (GS) Tool [
Even with well-structured data published using Linked Open Data6 and DSS, there can be conceptual gaps between the two systems, especially when decision criteria systems and application consumers need to function over a distributed service oriented architecture. These applications typically have requirements to track relationships across time, limitations, and other dependencies between conceptual entities. During the course of our research we have found a need to answer to these and other questions such as: { What is the relationship between two entities within the known world? { What dependencies, if any, exist between any two de ned entities? { How can I automate learning about relationship(s) and de ne comparisons? A larger goal that is currently being implemented as an extension to the GS work is to make linked data more portable between decision frameworks by automatically integrating sets of data from a variety of ontological structures as 3 The Green Scale: www.greenscale.org 4 GBXML: www.gbxml.org 5 BIM Extended Markup Language (BIMXML): www.bimxml.org 6 Linked Open Data: www.linkeddata.org a basis for switching between lower level data formats and schema. There is a need to compare one \entity" to another and calculate some relative relationship between them; this is the basis for the Relative Relationship (RR) Pattern7 and presented in this paper. The RR pattern can track relationships and thus is solving some of the issues of mapping between di erent geometry systems, ontologies, and other standards. The remainder of the paper describes pattern axioms, example pattern applications, and a discussion of potential implications. 2
The RR pattern relates entities [Table 1] to each other instead describing them
relative to a global \world frame" of reference. Applications are free, and
encouraged, to specify a world frame relative to an entity but this speci cation would
still be considered part of the body frame of that pattern instance for that entity.
Previous notions of scale, such as those mentioned in the related work section,
use a world frame to situate scaled objects. In both cases scale of some entity is
still part of some body frame or another and thus can be compared-or related-to
another if that translation could be tracked and would allow comparisons
between otherwise incomparable entities. This process of abstraction of situational
descriptions can be extended to other notions beyond physical existence. The
relationship of one entity relative to another explains how we perceive scale,
resolution, and conceptual analysis methods [
How can tracking such di erent concepts (physical, temporal, and informational data) be compared in any logical way? If the Relative Relationship (RR) pattern is considered momentarily as a \Meta-Pattern", then there of course would have to be categorical mechanisms in place so that coherent comparisons are maintained within di erent instances of the pattern-or at least this mechanism should inform the pattern as to the comparison types. To ease the conversation, a set of de nitions describing this pattern is included in Table 1. Additionally, Pattern Sequences are discussed which refer to collections of RR pattern instances working together for a larger purpose-they provide the fuller data perspectives necessary to feed/rank information into a DSS, for example. Dependency structures are also frequently mentioned, and this vocabulary indi7 http://ontologydesignpatterns.org/wiki/Submissions:RelativeRelationship 8 ODP: http://ontologydesignpatterns.org A physical object, object representation, piece of information, slice of time, or other \thing" that can be described by human perception or understanding that de nes some existence.
This is the instantiation of the pattern representation of an original Entity for a which a comparison is going to be made; it can be one of many attributes of the original Entity.
Relationship Description This describes the relationships being established between two entity representations via the Relative Existence property.
Domain
Usage Property Attribute
Scope Level of Detail
Description tag to determine the eld of study or data pattern of the instance-for additional interdisciplinary functionality.
An optional reference to distinguish between the multiple uses of RR instances and to organize pattern application intentions.
Data, characterization, quality of, or description about an established Relative Existence or Entity.
Description or quality of an established relationship type.
Set of scaled entities that are being considered together as a group/type or that are the extents of the known instances from the perspective of the pattern extents, data, or applications.
Selection out of all possible entities that could be considered in the group or added/removed as needed. This concept is not necessarily synonymous with or proportional to Scope or generality of information-it is application and instance dependent. cates a single type of Relationship Description used to track the reliance of one Relative Existence state against another, across pattern instances or sequences.
Within the building professions example, this also brings up the challenge of vocabulary and how scale is traditionally perceived. In fact, scale of an object can only be assigned in the presence of a relative comparison between itself and some other entity. For instance, an architectural drawing with scale x is only assigned said physical scale as a representation compared to the physical realization of itself. We consider Scale to be the de nition of the impact or perception of one entity relative to another; this can be a specialized \relative relationship." A variation of the RR pattern can capture relationships relative to an individual or system setting, or even two ideas, concepts, or values that may or may not be of equal importance. Similarly, various levels of intelligence need to e ectively cooperate together within their respective decision support systems to run full analyses; they also need to be capable of adjusting for new data sets as they became available or desirable for use. To integrate several types of ontologies or ontology patterns, it can be observed that again there is a comparison happening and decision being made between two or more entities and often their relative relationship needs determining for translations to be possible.
3.1
The Dynamic Relative Relationship Pattern [Figure 1] is intended to model not only physical data, but also temporal data, importance information, dependencies, and other data/entity relationship combinations. Required data for this purpose should at least have a base of four parts including: 1) an identi er for the respective entities, 2) each type of existence being recorded (i.e. how are we identifying this existence and representing each entity), 3) the relationship description being captured, and 4) which existence type is the target versus origin representations; additional information is based on the speci c needs the pattern is meeting. The format of the derived data is somewhat use-case-dependent, although now with the common underlying RR pattern structure [Table 1]. The signature of the Dynamic Relative Relationship Pattern consists of the set NC of classes (Eq. (1)), and NR of properties (Eq. (2)).
NC =fEntity; RelativeExistence; RelationshipDescription;
NR =frelativeExistenceOf; hasP roperty; determinedBy; hasU sage; hasDomain; involves; hasOrigin; hasT arget; hasAttribute; hasScope; hasBoundg (1) We assert pairwise disjointness between any two classes in NC except for the pair of Scope and LevelOf Detail. In particular, RelativeExistence is disjoint with Entity because a RelativeExistence is only an instantiation of an Entity in the context of some RelationshipDescription { it has no meaning outside the RelationshipDescription it is involved in. Scope and LevelOfDetail are not disjoint due to the fact that a Scope may not be contained to a single LevelOfDetail but a LevelOfDetail can refer to speci c Scope.
A RelationshipDescription involves at least two instances of RelativeExistence, including one considered as origin and one as target. Moreover, a RelativeExistence is a relative existence of exactly one Entity.
(3) (4) (5) (6) (7)
The pattern demands that the origin of a RelationshipDescription must be di erent from its target { given by the rule in (8), which cannot be expressed in OWL. This holds even when both RelativeExistences are associated with the same Entity. In other words, at least one aspect must be di erent between the origin and target, whether it is Domain, Property, or Usage. Applications may compare the same object and entity but instantiate the pattern at di erent states or points in time. For example, Features and types of each RelativeExistence can be in the form of a Property, Usage, or Domain, and can consist of none, one, or all of these properties. Properties can include physical descriptions (locations, geometry data, data, etc.), temporal features (timestamps, age, lifespan, decomposition rate, state limits, etc.), informational data (preferences, proportions, ranking factors, persistence limits, con dence intervals, etc.), and others. RelationshipDescription can also consist of none, one, or many attributes such as dependency structures, representational versus real world states, as well as scaling and transformation indicators, to name only a few.
RelationshipDescription(x) ^ hasOrigin(x; y) ^ hasT arget(x; z) ! y 6= z (8) The above rule can be expressed as OWL axioms below (though they will be beyond OWL 2 DL) where RRD BS ROT are fresh properties introduced specif
When populating this pattern, the RelationshipDescription class must be populated. That is, we do not allow, e.g., the Entity or RelativeExistence class to be populated without having RelationshipDescription populated too. This is not a typical requirement one would nd in a pattern description, however, this is considered necessary for the usability of this pattern in the application domain. This requirement can be expressed using the top property, i.e., owl:topProperty, denoted with U in this paper. The following axioms assert the existence of an instance of RelationshipDescription whenever the other classes are non-empty.
where X 2 fEntity; RelativeExistence; P roperty; U sage; Domain;
(12) ically for the purpose of simulating the rule. hasOrigin
RRD hasT arget v ROT
Irre exive(ROT ) RelationshipDescription 9RRD:Self
We assert guarded domain and range restrictions to all properties. Due to lack of space, we present how we can express these restrictions for the relativeExistenceOf property:
Speci c for hasProperty property, we have the following guarded domain and range restrictions:
A RelationshipDescription has at least one scope, and each scope has a bound of at least one level of detail.
A RelativeExistence may consist of one or more of Domain (hasDomainType), Usage (usageType), and/or Property (determinedBy).
RelativeExistence v 9hasDomain:Domain t 9hasU sage:U sage t 9determinedBy:P roperty (15) (9) (10) (11) (13) (14) (16) (17) (18) (19)
An entity that is the target of a RelativeExistence should also relate to RelativeExistence by having descriptions of itself in the same form as RelativeExistence, i.e. RelativeExistence would be a link to another instance of the Relative Relationship Pattern depicting the RelativeExistence of the referenced entity as well so that entities can be linked across detail levels, scale levels, and similar scopes, time, and importance changes (i.e. pattern instance sequences).
Relative Relationship Pattern Usage and Examples
Facilitation of data integration within decision frameworks is only one application example of using the RR Pattern as a Meta-Pattern to structure heterogeneous data and relationships. It can be used to track changes and dependencies, in conjunction with other patterns, or as an additional information layer for other patterns. Additionally, size and quality of instantiated patterns from many application domains can be established, and thus the data therein gains structured contextualization. All of these otherwise unconnected notions can in fact be compared and ranked together through a set of properties to create a viable pattern structure to handle Dynamic Relative Relationships.
To facilitate interoperability between all the components needed for better decision support, especially in an era of varied data types, formats, and locations, a dynamic RR meta-pattern is a useful layer to map the changes and relationships between varied data that is intended to be used seamlessly within applications. The larger scope of functionality that the RR pattern enables is a facilitation methodology for incorporating and maintaining linked data with decision support frameworks in a dynamic manner since aggregations of pattern instances create a tractable record of the relevant changes over time. 4.2
Structuring, formulating, and answering such questions as, "What sections of my house should I renovate for the most positive environmental impacts and lowest cost?", requires the cooperation of several infrastructural components including structured data, knowledge bases, reasoners, decisions support frameworks, etc. For simplicity, assume that budget only allows the user to decide between replacing brick or interior gypsum nishes, and that the respective data is accessible [Figure 2]. To know that the RR pattern can be successful, competency questions such as the following for the building industry domain (which already requires complex, multifaceted sets of data, processing procedures, and tools) should be able to be answered using the RR pattern: { Can I nd out more than just basic material replacement costs? { What will be e ected in the sequences if I select certain RR instances for replacement; i.e. what materials are structurally dependent on others, etc.? { Per this example, is an appropriate material found for replacement and what scope and range of materials are considered in that answer? @prefix : <http://purl.org/net/rr/RelativeRelationshipPattern#>. @prefix d: <http://rr-pattern.example/data#>. @prefix v: <http://rr-pattern.example/extvocab#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. v:CostToRepair rdfs:subClassOf :Property . v:Dependency rdfs:subClassOf :RelationshipDescription . d:brick rdf:type :Entity ; rdfs:label "Brick" . d:studs rdf:type :Entity ; rdfs:label "Studs" . d:insulation rdf:type :Entity ; rdfs:label "Insulation" . d:gypsum rdf:type :Entity ; rdfs:label "Gypsum" . d:brickrel1 rdf:type :RelativeExistence ; :relativeExistenceOf d:brick ; :determinedBy d:brickctp . d:brickctp a v:CostToRepair ; v:hasValue "3000"; v:hasUnit iso4217:USD . d:studsrel1 rdf:type :RelativeExistence; :relativeExistenceOf d:studs ; :determinedBy d:studsctp . d:studsctp a v:CostToRepair ; v:hasValue "1000"; v:hasUnit iso4217:USD . d:insulrel1 a :RelativeExistence; :relativeExistenceOf d:insulation ; :determinedBy d:insulctp . d:insulctp a v:CostToRepair ; v:hasValue "2000"; v:hasUnit iso4217:USD . d:gypsrel1 rdf:type :RelativeExisttence; :relativeExistenceOf d:gypsum ; :determinedBy d:gypsctp . d:gypsctp a v:CostToRepair ; v:hasValue "2000"; v:hasUnit iso4217:USD . d:dep1 a v:Dependency; :hasOrigin d:studsrel1 ;
:hasTarget d:insulre1, d:gypsrel1 . d:dep2 a v:Dependency; :hasOrigin d:gypsrel1; :hasTarget d:insulrel1.
To structure this query, assume wall assemblies are made of brick, studs, insulation, and gypsum. This question can potentially be an attribute or potential component of a preference model, but currently this remains partially speculation. Suppose RR Pattern instances represent the building model geometric relationships via IFC or gbXML, but now with component relationship information. Simplistically, the data knows that the brick has stud dependencies (brick hold studs in place), the studs have dependencies of gypsum and insulation, etc. [Figure 3], and depending on the open/closed world assumptions and query style, the reverse information indicating that no dependency exists is potentially also available. Depending on data, the RR pattern might also include material costs, ages, lifespans, and decomposition rates as entity relationship properties. Regardless, a query for minimum replacement cost may yield that gypsum alone is cheaper to replace than brick [Figure 4]; but, the RR Pattern can use its dependency structure to determine that this initially cheaper choice will mean exposing insulation (perhaps asbestos) which will then also require immediate replacement, making the originally cheaper option cost more when gypsum and insulation costs are aggregated together [Figure 5]. Returning to the original competency questions, these pattern instances do indeed give better insight into the user query than a list of base material costs; the dependency structure allows tabulations to be found for all materials that will contribute to building costs as a result of changing the original. The string of dependencies themselves, among other data, are also discoverable individually, leading to possibilities for even more accurate visualizations, decision impact, and overall understanding. Based on [Figure 5], a reasonable answer is found (brick) which is drastically di erent than a similar query not using the bene cial structures of the RR Pattern. SELECT ?name ?cost WHERE {
VALUES ?name { "Brick" "Gypsum" } [] :relativeExistenceOf [ a :Entity; rdfs:label ?name ] ;
:determinedBy [a v:costToRepair ; v:hasValue ?cost ] . } ORDER BY ?cost ?name ?cost "Gypsum" "2000" "Brick" "3000" Fig. 4. Query for the repair cost of materials of Brick and Gypsum and order them from the cheapest to most expensive via replacement cost, without considering dependencies. SELECT ?basename ( SUM(?cost) AS ?totalcost )
( GROUP_CONCAT(?name; separator=",") AS ?reqs ) WHERE { { SELECT ?basere ?basename WHERE {
VALUES ?basename { "Brick" "Gypsum" } ?basere :relativeExistenceOf [ a :Entity; rdfs:label ?basename ] . } } ?basere (^hasOrigin/hasTarget)* ?re . ?re :relativeExisenceOf [ a :Entity; rdfs:label ?name ];
:determinedBy [a v:costToRepair; v:hasValue ?cost] .
} GROUP BY ?basename
?name ?totalcost ?reqs
"Brick" "3000" "Brick"
"Gypsum" "4000" "Gypsum, Insulation"
Useful background work exists such as representing geographical scale
compatibility over space and time [
A dynamic data relationship pattern was presented in the context of a current research use case in the building industry domain, as well as suggested application integration possibilities. A dependency scenario was also provided for 9 Integrating Multiple Domains and Scales: https://goo.gl/SaVFRi dynamically determining, establishing, and tracking relative relationships. The Relative Relationship Pattern establishes hierarchies between di erent entities, idea conceptualizations, and data sets to e ciently track changes and dependencies within physical, temporal, and informational relationships. This means that application queries can be formulated to return data about individual \entities", but more importantly how two entities relate to each other and how those relationships-real or representational-can be tracked over time and through changes in state conditions. It can also potentially facilitate connections between knowledge graphs and decision frameworks that consume the data; this happens by creating an \upper" conceptual layer of information which can potentially enable more powerful inferencing and more accurate predictions. Acknowledgments. Thank you to the Center for Research Computing (CRC) at the University of Notre Dame, and Jarek Nabrzyski, CRC Director, and also the Green Scale Project. Adila Krisnadhi acknowledges the support of the National Science Foundation under the award 1440202 "EarthCube Building Blocks: Collaborative Proposal: GeoLink { Leveraging Semantics and Linked Data for Data Sharing and Discovery in the Geosciences."