Property:ContentODPDescription
From Odp
This property is of type Text.
This property is a subproperty of PatternSolution.
(previous 25) (next 25)
Pages using the property "ContentODPDescription"
Showing 25 pages using this property.
S | |
|---|---|
| SmartHome TimeInterval + | Specializing the OWL-Time ontology |
| Social Reality (OWL 2) + | Using the approach taken in [[Submissions: … Using the approach taken in [[Submissions:N-Ary_Relation_Pattern_(OWL_2)]] we place an observer relative fact (OR) in a context (the observer, C) and the brute fact (BF). For the theory This is a reified relation, and we then specify a role chain that allows us to directly relate the observer (context C) to the brute fact using a relation that reflects the fact that the brute fact counts-as some observer relative fact. See Searle, 1995 (construction of social reality) and/or: Rinke Hoekstra. Ontology Representation – Design Patterns and Ontologies that Make Sense, volume 197 of Frontiers of Artificial Intelligence and Applications. IOS Press, Amsterdam, June 2009. Rinke Hoekstra. Representing social reality in owl 2. In Evren Sirin and Kendall Clark, editors, Proceedings of OWLED 2010, June 2010. for the details of this theory. une 2010. for the details of this theory. |
| Spatial Graph Adapter (SGA) + | After several iterations of studying build … After several iterations of studying building industry data standards (in particular, GBXML, IFC, and CityGML), we began to map not only terms between them, but also conceptual level indicators. First we capture the main spatial arrangement of geometric elements which are extracted automatically from a spatial instance file. Secondly, the SGA pattern allows us to contextualize additional relationships to capture schema-specific ideas to ultimately be able to ask all the data questions simultaneously. We do acknowledge that in several cases there could be benefits to aligning it with other mereotopological or SIO pattern concepts, but these have not been necessary thus far. Even if we use a common definition for adjacency, such as where two objects would be touching could be considered adjacent, this fails when we want to know, say what columns or walls are adjacent to a space. It is true that they may be touching some building geometries, but what about the cases where you would have adjacent columns, but they are touching only the open air that define that side of a space (not touching but still on that visual or schema induced boundary)? The SGA pattern allows us to extract this type of information and add it as Attributes or ContextualizedRelations to other objects, solving this issue by being able to, for example, group building elements even as what may seem arbitrary in isolated examples. Schemas produce a wide array of these situations, and even more when we start to translate between them. e when we start to translate between them. |
| SpatioTemporalExtent + | See Adila Krisnadhi, Pascal Hitzler, Krzysztof Janowicz. A Spatiotemporal Extent Pattern based on Semantic Trajectories. Under review for WOP 2016. |
| SpeciesBathymetry + | --- |
| SpeciesConditions + | - |
| SpeciesConservation + | -- |
| SpeciesEat + | ... |
| SpeciesHabitat + | --- |
| SpeciesNames + | -- |
| Standard Enforcer Pattern + | SEP provides a mechanism to ontologically … SEP provides a mechanism to ontologically declare the conformance of a process with one or more standards. The pattern is flexible and compositional. It can be exploited to include few or more guidelines from multiple standards and can be easily combined with other patterns. an be easily combined with other patterns. |
T | |
| Tagging + | Tagging pattern exploits the [[Submissions:Situation|Situation]] pattern in order to encode Gruber's definition that has tagging as a relation between an agent, a tag from a folksonomy, a content tagged, a polarity. |
| TaskExecution + | ---- |
| Template Instance + | The pattern proposes to use the same “temp … The pattern proposes to use the same “template” instance as the value of a reified property for multiple subjects (rather than having multiple copies of the same reified instance). The diagram presents an example of the usage of the pattern, for an easier understanding. The individuals <code style="font-size:larger;">x1</code>, <code style="font-size:larger;">x2</code> and <code style="font-size:larger;">x3</code> have a reified property <code style="font-size:larger;">p</code> that have as values the reified individuals, <code style="font-size:larger;">y1</code>, <code style="font-size:larger;">y2</code> and <code style="font-size:larger;">y3</code>, respectively. In OWL, we would have object property assertions: <code style="font-size:larger;">(x1 p y1)</code>, <code style="font-size:larger;">(x2 p y2)</code>, <code style="font-size:larger;">(x3 p y3)</code>. The properties for the reified individuals, <code style="font-size:larger;">y1</code>, <code style="font-size:larger;">y2</code> and <code style="font-size:larger;">y3</code> are all identical: <code style="font-size:larger;">(y_ p1 foo)</code>, <code style="font-size:larger;">(y_ p2 1.0)</code> and <code style="font-size:larger;">(y_ p3 z)</code>. The pattern proposes to create a template instance, <code style="font-size:larger;">y_tmpl</code> having the common values as its property values: <code style="font-size:larger;">(y_tmpl p1 foo), (y_tmpl p2 1.0), (y_tmpl p3 z)</code> The template instance would be used as the value for the reified property for <code style="font-size:larger;">x1</code>, <code style="font-size:larger;">x2</code> and <code style="font-size:larger;">x3</code>: <code style="font-size:larger;">(x1 p y_tmpl), (x2 p y_tmpl), (x3 p y_tmpl)</code> In addition, we will also add one annotation property, <code style="font-size:larger;">isTemplate:true</code>, on <code style="font-size:larger;">y_tmpl</code> to mark that it as a template instance. The intention is that the template instance is immutable, i.e., the property values of the template instance cannot be changed. <br /> In the case that a user would like to change a property value of the reified relation, a clone of the template instance would be created and the change would occur on the clone. An ontology editor would use the <var>isTemplate</var> annotation property to check that a certain instance cannot be modified, and it should rather create a clone. The right side of the diagram gives an example of this situation. Say that at a given time t<sub>0</sub>, there was an additional x4 individual that had the template instance as the value for p. At t<sub>0</sub>: <code style="font-size:larger;">(x4 p y_tmpl)<br /> (y_tmpl p1 foo), (y_tmpl p2 1.0), (y_tmpl p3 z)</code> Later, at time t<sub>1</sub>, the user decides to change the value <code style="font-size:larger;">p1</code> on x4 from “foo” to “bar”. The ontology editor (or the user, if there is no support in the tool), will see the <var>isTemplate</var> annotation property on <code style="font-size:larger;">y_tmpl</code> as set on true, and it will create a clone of it, <code style="font-size:larger;">y_tmpl_modif</code>, by cloning also all the object and data property axioms. Then, it will change the value of <code style="font-size:larger;">p1</code> on <code style="font-size:larger;">y_tmpl_modif</code>. So, the result will be: At t<sub>1</sub>: <code style="font-size:larger;">(x4 p y_tmpl_modif)<br /> (y_tmpl_modif p1 bar), (y_tmpl_modif p2 1.0), (y_tmpl_modif p3 z)</code> <br /> As a result of using the Template Instance pattern, one could reduce the number of data and object property axioms in the ontology. This “deflation” of the ontology is especially significant, if there are many repetitive values in the ontology, with very few changes, and if the number of properties of the reified instances is large. perties of the reified instances is large. |
| Time indexed participation + | This pattern uses the [[Submissions:Situation|Situation]] pattern to add temporal information to participation of objects into events. |
| Time indexed person role + | This pattern is encoded by specializing the situation pattern and composing it with the agent role pattern. |
| TimeIndexedClassification + | --- |
| TimeIndexedPartOf + | -*- |
| TimeIndexedSituation + | This pattern adds a time specification (the [[Submissions:TimeInterval|Time interval]] pattern) to the [[Submissions:Situation|Situation]] pattern, in order to provide a handy solution to many cases. |
| TimeInterval + | -- |
| TimePeriod + | A time period is modelled as a n-ary relation with a measurement unit and a numerical value. |
| Topic + | Topics are modelled as conceptual complexes with part of (containment), overlap, and vicinity relations, and can be related to any kind of entity. They are disjoint from "Concepts", which can be at the "core" of topics. |
| Trajectory + | This pattern is reengineered from [Hu, et al., COSIT 2013] with changes as described in the intent of the pattern. |
| Transition + | This pattern composes the [[Submissions:Ti … This pattern composes the [[Submissions:Time indexed participation|Time-indexed participation]], [[Submissions:Region|Region]], and [[Submissions:Sequence|Sequence]] patterns in order to represent changing of states for objects, fired by some event, through an underlying process. some event, through an underlying process. |
| TransportPattern + | The rive water was polluted from effluent near a large factory. A package left Auckland, New Zealand, at 5:45am on 01/06/2012 and arrived in Los Angeles, USA, on 01/12/2012. |
