Use Case Bridging OWL and UML

From Library Linked Data
Revision as of 15:26, 18 October 2010 by Jyoung4 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Back to Use Cases & Case Studies page

Name

The Wiki page URL should be of the form "Use_Case_Name", where Name is a short name by which we can refer to the use case in discussions. The Wiki page URL can act as a URI identifier for the use case.

Bridging OWL and UML

Owner

The person responsible for maintaining the correctness/completeness of this use case. Most obviously, this would be the creator.

Jeff Young

Background and Current Practice

Where this use case takes place in a specific domain, and so requires some prior information to understand, this section is used to describe that domain. As far as possible, please put explanation of the domain in here, to keep the scenario as short as possible. If this scenario is best illustrated by showing how applying technology could replace current existing practice, then this section can be used to describe the current practice. Often, the key to why a use case is important also lies in what problem would occur if it was not achieved, or what problem means it is hard to achieve.

First Principles

The first principle of Linked Data is:

  1. Use URIs as names for things

If you think it is easy to name things, you are categorically right and categorically naive. If names are not systematically managed by domain experts they easily become incoherent and/or tightly coupled making unexpected reuse impossible or chaotic. To prevent this, names should be rationalized in an adaptable conceptual model that is based on use cases and managed with sensible meta-model language(s). Web Ontology Language (OWL) and Uniform Modeling Language (UML) are two such languages that could be content-negotiated in either direction to manage and represent a common domain model. OWL representations are most effective for machine consumption while UML is most effective for human consumption. The UML community has developed the Ontology Definition Metamodel (ODM) to help bridge this gap, but examples are still in short supply. This use case is intended to narrow this gap considerably.

Goal

Two short statements stating (1) what is achieved in the scenario without reference to linked data, and (2) how we use linked data technology to achieve this goal.

  1. Illustrate how UML class diagrams can be used to explore, reuse, and design OWL
  2. If you avoid bells and whistles in both languages, all Linked Data resources can be represented using UML class diagrams and vice versa.

Target Audience

The main audience of your case. For example scholars, the general public, service providers, archivists, computer programs...

Use Case Scenario

The use case scenario itself, described as a story in which actors interact with systems. This section should focus on the user needs in this scenario. Do not mention technical aspects and/or the use of linked data.

A domain expert and a modeling expert meet to discuss a new Web use case. The domain expert brings an "elevator speech" from which the modeling expert circles the terms/concepts that seem to be essential. He and the domain expert then deposit and sort out these terms in a UML class diagram after which the modeler asks questions and listens for other terms/concepts to flesh out, clarify, rename, formalize, and abstract the logical/conceptual model to match the domain expert's understanding. The modeling expert probes each term for hidden meaning and a good thesaurus comes in handy. The result is a set of essential names for things that are categorized and related according to UML's metamodel: class, attribute, association, operation, instance, etc.

During this process, the domain expert mentions that some of the information already exists in a relational database and some in an XML database. The domain modeler tracks down the schemas for these and adds them to the UML model. Because these names are part of the physical data model designed for earlier use cases, though, this part of model should go through the same conceptual modeling process with care taken to separate and map the physical/conceptual models.

Application of linked data for the given use case

This section describes how linked data technology could be used to support the use case above. Try to focus on linked data on an abstract level, without mentioning concrete applications and/or vocabularies. Hint: Nothing library domain specific.

An example domain model represented in two Web document representations:

Existing Work (optional)

This section is used to refer to existing technologies or approaches which achieve the use case. Hint: Specific approaches in the library domain.

Related Vocabularies (optional)

Here you can list and clarify the use of vocabularies (element sets and value vocabularies) which can be helpful and applied within this context.

Problems and Limitations

This section lists reasons why this scenario is or may be difficult to achieve, including pre-requisites which may not be met, technological obstacles etc. Please explicitly list here the technical challenges made apparent by this use case. This will aid in creating a roadmap to overcome those challenges.


Related Use Cases and Unanticipated Uses (optional)

The scenario above describes a particular case of using linked data.. However, by allowing this scenario to take place, the likely solution allows for other use cases. This section captures unanticipated uses of the same system apparent in the use case scenario.

Library Linked Data Dimensions / Topics

The dimensions and topics are used to organize the use cases. At the same time, they might help you to identify additional aspects currently not covered. If appropriate topics and/or dimensions are missing, please specify them here and annotate them by a “*”.



*these items are not in the initial list, suggestion for adding them


References (optional)

This section is used to refer to cited literature and quoted websites.