AdilaKrisnadhi at 22:04, 17 July 2016

2016-07-17T22:04:48Z

AdilaKrisnadhi: New page: {{Logical_OP_Proposal_toolbar}} {{Graphical representation header}} {{Graphical representation |ImageName=Stub-metapattern.png }} {{Logical OP General Template |Name=Stub Metapattern |Subm...

2016-07-17T21:51:19Z

New page: {{Logical_OP_Proposal_toolbar}} {{Graphical representation header}} {{Graphical representation |ImageName=Stub-metapattern.png }} {{Logical OP General Template |Name=Stub Metapattern |Subm...

New page

{{Logical_OP_Proposal_toolbar}}
{{Graphical representation header}}
{{Graphical representation
|ImageName=Stub-metapattern.png
}}
{{Logical OP General Template
|Name=Stub Metapattern
|SubmittedBy=AdilaKrisnadhi
|Author=Adila Krisnadhi, Pascal Hitzler
}}
{{Logical OP Description Template
|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.

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=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
}}
{{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.

- 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]]
|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.
}}
{{Logical OP Reference Template
|Origin=Adila Krisnadhi, Pascal Hitzler. The Stub Metapattern. Under review at WOP 2016.
}}
{{Additional information header}}

{{Scenarios about me}}
{{Reviews about me}}
{{Modeling issues about me}}
{{My references}}
{{Submission to event
|Event=WOP:2016
}}

@@ 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.
-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.
 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=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>
-- Replace the variable class <ClassName> with the class Place
+Axiom patterns (in Manchester Syntax):
-- 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.
+* Replace the variable class <ClassName> with the class Place

Submissions:Stub Metapattern - Revision history

AdilaKrisnadhi at 22:04, 17 July 2016

AdilaKrisnadhi: New page: {{Logical_OP_Proposal_toolbar}} {{Graphical representation header}} {{Graphical representation |ImageName=Stub-metapattern.png }} {{Logical OP General Template |Name=Stub Metapattern |Subm...