Revising Use Cases: Generic heterogeneous schema and instance dat a support

Hi Team,

At the telecon last week one of the things we discussed is the need to
reduce the number of use cases. I have a proposal for how to do this. It
seems that 4 of the use cases are instances of a more generic use case that
requires full lifecycle support for heteregeneous schema and instance data.
So my proposal is to group these use cases under this generic use case. Then
we can try to implement the generic use case, while paying attention to
trying to solve one or more of the specific instances. What do people think?
The other observation is should be fairly easy to identify the prototypes
relevant to this generic use case, which will make it easier to proritise
the prototypes as well?

Feedback either via email or on the call tomorrow is very welcome?

Proposal:

HETEROGENEOUS SCHEMA AND INSTANCE DATA SUPPORT

This use case addresses two of the key challenges that SIMILE is
considering: supporting the flexible evolution of arbitrary metadata schemas
for library collections that are domain or discipline-based. We have a
identified a number of real-world exemplars of this generic use case that
are discussed in subsequent sections: Learning Object Support, Visual Images
Support, Biomedical Images Support and Schema and Vocabulary Registry and
Search. The generic use case may be decomposed into several different
sub-use cases: 

1. A community approaches the library to store metadata about a collection
where they currently possess no metadata or ontology. 
- Using an appropriate UI, search existing ontologies and create a new
ontology reusing elements of existing ontologies classes where appropriate.
Automatically generate a description of this ontology. 
- Using the ontology, (perhaps automatically) create a user interface for
entering instance data for the ontology. 
- Create a suitable validation scheme for the ontology. 
- Register the schema, the user interface and the schema validation
information with SIMILE. 
- Enter instance data using the new ontology, UI and validation scheme. 

2. A community approaches the library to store metadata about the collection
where they currently possess metadata and a metadata schema in a
non-standard form e.g. CDIF or a relational database. 
- Using an appropriate UI, search existing ontologies and create a new
ontology reusing elements of existing ontologies classes where appropriate
that maps onto the existing schema. Automatically generate a description of
this ontology. 
- Create a user interface that will allow the librarian to inspect the
quality of the instance data based on the new schema. 
- Register the new ontology and UI with SIMILE. 
- Write a piece of custom software that takes the legacy metadata format and
converts it to RDF for ingestion into SIMILE. 
- Convert the legacy data to RDF and ingest it into SIMILE. 
Example: Learning Objects Use Case, Visual Images Support, Biomedical
Images. 

3. A community approaches the library to store metadata about a collection
where they currently possess XML metadata and an XML schema. 
- Using an appropriate UI, search existing ontologies and create a new
ontology reusing elements of existing ontologies classes where appropriate
that maps onto the existing schema. Automatically generate a description of
this ontology. 
- Create a user interface that will allow interaction with instance data and
allow the librarian to inspect the quality of the instance data based on the
new schema. 
- Register the new schemas and user interface with SIMILE. 
- Write an XSLT stylesheet that takes the XML and converts it to RDF/XML for
importation into SIMILE. 
- Convert the legacy data to RDF and ingest it into SIMILE. 

4. A community approaches the library to store metadata about a collection
where they currently possess RDF metadata and suitable ontology information.

- If the data to be ingested uses an ontology not already registered with
SIMILE, try to relate the schema to existing vocabulary elements wherever
possible. 
- If no user interface exists for the ontology, create a user interface that
will allow interaction with instance data. 
- If the ontology and / or the UI are not already registered with SIMILE
register them. 
- Ingest the data into SIMILE. 

5. Once an schema is managed by SIMILE, it may be necessary to revise the
schema e.g. add fields, remove fields, provide additional relations between
the schema and other schemas. 

6. Navigate and search the instance data, hiding the underlying complexity
of the heterogeneous ontologies from the user. 

7. Support adding and editing existing instance data i.e. the full lifecycle
for instance data. 

This use case will adopt the following simplifying assumptions:
- This use case will not consider federation. It will assume a centralised
repository of ontology, user interface and validation information. 
- It will assume that the canoncial version of the instance data is held in
SIMILE i.e. it is not necessary to reingest data because the canonical
version is elsewhere. If, when information is updated in SIMILE it is
required that the instance data is also updated in external systems it is
the responsibility of those external systems 
to update their information. 

regards

Dr Mark H. Butler
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

Received on Thursday, 19 June 2003 06:40:11 UTC