Submissions:Stub Metapattern

From Odp

(Difference between revisions)
Jump to: navigation, search
(New page: {{Logical_OP_Proposal_toolbar}} {{Graphical representation header}} {{Graphical representation |ImageName=Stub-metapattern.png }} {{Logical OP General Template |Name=Stub Metapattern |Subm...)
Current revision (22:04, 17 July 2016) (view source)
 
Line 12: Line 12:
|Motivation=When modeling an ontology, one of the issues to be addressed is that of granularity: To what detail should the ontology represent the notions it captures? Traditionally, this issue is resolved by looking at a concise definition of the use cases, e.g. by means of competency questions. As a result of this, some parts of the ontology may be modeled in a rather fine-grained manner, while other parts remain relatively coarse.  
|Motivation=When modeling an ontology, one of the issues to be addressed is that of granularity: To what detail should the ontology represent the notions it captures? Traditionally, this issue is resolved by looking at a concise definition of the use cases, e.g. by means of competency questions. As a result of this, some parts of the ontology may be modeled in a rather fine-grained manner, while other parts remain relatively coarse.  
-
A straightforward handling of differing granularity requirements in different parts of an ontology can make it more difficult to repurpose or extend the ontology, or to use it in an ontology-driven data integration setting. The reason is that because one is often faced with a situation where (s)he has to decide whether to represent a notion as a literal value (e.g., a string) or an ontology entity such as a class. Choosing one over the other introduces a commitment that one may regret later on.  
+
A straightforward handling of differing granularity requirements in different parts of an ontology can make it more difficult to repurpose or extend the ontology, or to use it in an ontology-driven data integration setting. The reason is that because one is often faced with a situation where (s)he has to decide whether to represent a notion as a string literal value or an ontology entity such as a class. Choosing one over the other introduces a commitment that one may regret later on.  
For example, when modeling a location, one could use the location name as a string or model it as a possibly full-blown pattern for the notion of Place. Choosing the former may prevent future use case of data enrichment, e.g., for expressing co-location (as one cannot use owl:sameAs relation between two strings). Choosing the latter means committing to a particular way of modeling Place, which may not necessarily be desirable in the future.
For example, when modeling a location, one could use the location name as a string or model it as a possibly full-blown pattern for the notion of Place. Choosing the former may prevent future use case of data enrichment, e.g., for expressing co-location (as one cannot use owl:sameAs relation between two strings). Choosing the latter means committing to a particular way of modeling Place, which may not necessarily be desirable in the future.
This pattern provides a way to solve this problem is to essentially keep both in the model, i.e., by including the literal value in the model, while employing a very minimalistic pattern for the notion. The latter is realized only as a single class.
This pattern provides a way to solve this problem is to essentially keep both in the model, i.e., by including the literal value in the model, while employing a very minimalistic pattern for the notion. The latter is realized only as a single class.
-
 
-
 
|Aim=The aim of this metapattern is to act as a type of placeholder for future extensions of an ontology in cases where a more fine-grained modeling would currently be counterproductive, but future extensions may call for more details.
|Aim=The aim of this metapattern is to act as a type of placeholder for future extensions of an ontology in cases where a more fine-grained modeling would currently be counterproductive, but future extensions may call for more details.
|Solution=The solution is a metapattern. That is, it uses one "variable" class and two "variable" properties. The intention here is that when one wishes to use this metapattern, (s)he needs to instantiate the "variable" class and properties into actual class and properties. See Example section for a more concrete example.
|Solution=The solution is a metapattern. That is, it uses one "variable" class and two "variable" properties. The intention here is that when one wishes to use this metapattern, (s)he needs to instantiate the "variable" class and properties into actual class and properties. See Example section for a more concrete example.
-
|Elements=owl:Thing, xsd:string, variable class: <ClassName>, variable object property: hasAssociated<ClassName>, variable data property: <ClassName>KnownAs
+
|Elements=Entities and variable entities:
-
}}
+
* owl:Thing
-
{{Logical OP Example Template
+
* xsd:string
-
|ProblemExample=One wishes to instantiate the Stub Metapattern for representing the notion of Place. To do it, the following steps need to be done.
+
* variable class: <ClassName>
 +
* variable object property: hasAssociated<ClassName>
 +
* variable data property: <ClassName>KnownAs
-
- Replace the variable class <ClassName> with the class Place
+
Axiom patterns (in Manchester Syntax):
 +
* hasAssociated<ClassName> Range <ClassName>
 +
* <ClassName>KnownAs Range xsd:string
 +
* <ClassName>KnownAs some xsd:string SubClassOf: <ClassName>
 +
* <ClassName> SubClassOf: <ClassName>KnownAs some xsd:string
-
- Replace the variable object property hasAssociated<ClassName> with hasAssociatedPlace
 
-
- Replace the variable data property <ClassName>KnownAs with PlaceKnownAs
+
}}
 +
{{Logical OP Example Template
 +
|ProblemExample=One wishes to instantiate the Stub Metapattern for representing the notion of Place. To do it, the following steps need to be done in all of the axiom patterns.
-
- If desired, the properties may be renamed to something more appropriate with the problem at hand, e.g., rename PlaceKnownAs into placeKnownAs if CamelCase naming convention is used.
+
* Replace the variable class <ClassName> with the class Place
 +
* Replace the variable object property hasAssociated<ClassName> with hasAssociatedPlace
 +
* Replace the variable data property <ClassName>KnownAs with PlaceKnownAs
 +
* If desired, the properties may be renamed to something more appropriate with the problem at hand, e.g., rename PlaceKnownAs into placeKnownAs if CamelCase naming convention is used.

Current revision


This pattern has been certified.

Related submission, with evaluation history, can be found here

If you are a member of quality committee please visit the

evaluation section

If you are author of this proposal or you want to contribute to this pattern's review, you can:

In general, it could be useful to visit the evaluation section to have information about the evaluation process of this proposal

Current revision ID: 12798

Graphical representation

Diagram

Image:Stub-metapattern.png

General information

Name Stub Metapattern
Also known as
Author(s) Adila Krisnadhi, Pascal Hitzler
SubmittedBy AdilaKrisnadhi


Description

Motivation When modeling an ontology, one of the issues to be addressed is that of granularity: To what detail should the ontology represent the notions it captures? Traditionally, this issue is resolved by looking at a concise definition of the use cases, e.g. by means of competency questions. As a result of this, some parts of the ontology may be modeled in a rather fine-grained manner, while other parts remain relatively coarse.

A straightforward handling of differing granularity requirements in different parts of an ontology can make it more difficult to repurpose or extend the ontology, or to use it in an ontology-driven data integration setting. The reason is that because one is often faced with a situation where (s)he has to decide whether to represent a notion as a string literal value or an ontology entity such as a class. Choosing one over the other introduces a commitment that one may regret later on.

For example, when modeling a location, one could use the location name as a string or model it as a possibly full-blown pattern for the notion of Place. Choosing the former may prevent future use case of data enrichment, e.g., for expressing co-location (as one cannot use owl:sameAs relation between two strings). Choosing the latter means committing to a particular way of modeling Place, which may not necessarily be desirable in the future.

This pattern provides a way to solve this problem is to essentially keep both in the model, i.e., by including the literal value in the model, while employing a very minimalistic pattern for the notion. The latter is realized only as a single class.

Aim The aim of this metapattern is to act as a type of placeholder for future extensions of an ontology in cases where a more fine-grained modeling would currently be counterproductive, but future extensions may call for more details.
Solution description The solution is a metapattern. That is, it uses one "variable" class and two "variable" properties. The intention here is that when one wishes to use this metapattern, (s)he needs to instantiate the "variable" class and properties into actual class and properties. See Example section for a more concrete example.
Elements Entities and variable entities:
  • owl:Thing
  • xsd:string
  • variable class: <ClassName>
  • variable object property: hasAssociated<ClassName>
  • variable data property: <ClassName>KnownAs

Axiom patterns (in Manchester Syntax):

  • hasAssociated<ClassName> Range <ClassName>
  • <ClassName>KnownAs Range xsd:string
  • <ClassName>KnownAs some xsd:string SubClassOf: <ClassName>
  • <ClassName> SubClassOf: <ClassName>KnownAs some xsd:string
Implementation
Reusable component
Component type


Example

Problem example One wishes to instantiate the Stub Metapattern for representing the notion of Place. To do it, the following steps need to be done in all of the axiom patterns.
  • Replace the variable class <ClassName> with the class Place
  • Replace the variable object property hasAssociated<ClassName> with hasAssociatedPlace
  • Replace the variable data property <ClassName>KnownAs with PlaceKnownAs
  • If desired, the properties may be renamed to something more appropriate with the problem at hand, e.g., rename PlaceKnownAs into placeKnownAs if CamelCase naming convention is used.


Image:Stub-metapattern-instantiationexample.png

Pattern solution example
Consequences A concrete minimalistic pattern for Place is obtained, which already facilitates the use of both URI and literal value to identify a particular place/location.


Pattern reference

Origin Adila Krisnadhi, Pascal Hitzler. The Stub Metapattern. Under review at WOP 2016.
Known use
Reference
Related ODP
Used in combination with
Test

Additional information

Scenarios

Scenarios about Stub Metapattern

No scenario is added to this Content OP.

Reviews

Reviews about Stub Metapattern

There is no review about this proposal. This revision (revision ID 12798) takes in account the reviews: none

Other info at evaluation tab


Modeling issues

Modeling issues about Stub Metapattern

There is no Modeling issue related to this proposal.


References

Add a reference


Submission to event

WOP:2016

Personal tools
Quality Committee
Content OP publishers