1. When to Use an Ontology
- Knowledge management
1) control vocabulary
2) making domain assumptions more explicit
3) separate the metadata structure from the data itself
4) change in metadata does not necessarily require change in the data
- Knowledge sharing
1) the clear model of your data enables other machines and people to understand it, and thus and reuse it
- Knowledge integration
1) ontologies can bridge between several data sources
- Knowledge analysis
1) using a rich data model enables more complex analysis to be made on the data
- Type of Ontologies
1) Representation ontologies
* describe low-level primitive representations
e.g. OWL, RDF, RDF Schema (language itself)
2) General or upper-level ontologies
* describe high-level, abstract, concepts
e.g. Cyc (Commonsense ontology)
3) Domain ontologies
* describe a particular domain extensively
e.g. GO (Gene Ontology), CIDOC CRM (for cultural heritage)
4) Application ontologies
* mainly designed to answer to the needs of a particular application
e.g. FOAF(Friend Of A Friend)
https://en.wikipedia.org/wiki/Ontology_engineering
http://owl.cs.manchester.ac.uk/about/ontology-engineering/
2. Ontology Building Methodologies
: no standard methodology for ontology construction
- Ontology Development Life-Cycle
1) Specification: specifying the ontology's purpose and scope
* why are you building this ontology?
* what will this ontology be used for?
* what is the domain of interest?
* how much detail do you need?
* Competency Questions: what are some questions you need the ontology to answer?
2) Conceptualisation: identifying the concepts to include in your ontology, and how they relate to each other
* what can you reuse?
* ontologies are meant to be reusable!
3) Formalisation: moving from a list of concepts to a formal model
* define the hierarchy of concepts and relations: top-down/bottom-up / middle-out
* class or relation? : if the subclass doesn't need any new relations (or restriction), then consider making it a relation
* class or instance? : if it can have its own instances or subclasses, then it should be a class
4) Implementation: choosing a language and implementing it with an ontology editor
5) Evaluation: implementing the ontology in an ontology editor helps to get syntax correct
* check the ontology against your competency questions
* W3C RDF validator: http://www.w3.org/RDF/Validator/
6) Documentation: documenting the design and implementation rational is crucial for future usability and understanding of the ontology
http://wiki.opensemanticframework.org/index.php/Ontology_Development_Methodologies
3. Conceptual modelling
- Conceptualisation (1): Vocabulary
1) what are the terms we would like to talk about?
2) what properties do those terms have?
3) competency questions provide a useful starting point
4) investigating homonyms and synonyms
- Conceptualisation (2): Classes
1) select the terms that represent objects having independent existence rather than terms that describe these objects
2) classes represent concepts in the domain and not the words that denote these concepts
3) typically nouns and nominal phrases, but not restricted to them
- Conceptualisation (3): Class hierarchy
1) a subclass represents a concept that is a 'kind of' the concept that the superclass represents
2) Roles are not subclasses
3) application dependent or subjective
- Conceptualisation (4): Properties
1) for each property in the list, we must determine which class it describes
* attributes: measurable properties of a class
* relationships: inter-entity connections
- Conceptualisation (5): Domain and range
1) refine the semantics of the properties
2) when defining a domain or a range for a slot, find the most general classes or class that can be respectively the domain or the range of the slots
- Conceptualisation (6): Inverse properties
1) modelling with inverse properties is redundant, but allows acquisition of the information in either direction
- Conceptualisation (7): Instances
1) entities of a certain type
댓글 없음:
댓글 쓰기