Submissions:Stub Metapattern
From Odp
(Difference between revisions)
(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 | + | 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 | + | |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 | ||
| - | |||
| - | + | }} | |
| + | {{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. | ||
| - | + | * 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
| If you are a member of quality committee please visit the
If you are author of this proposal or you want to contribute to this pattern's review, you can: specify if this revision takes in account any of the review(s) 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
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:
Axiom patterns (in Manchester Syntax):
|
| 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.
|
|---|---|
| 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
| Submission to event |
|---|
