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

Reducing the span of use cases is good.

> Then
> we can try to implement the generic use case, while paying attention to
> trying to solve one or more of the specific instances. 

One piece of advice that I have heard (and regret not following more often!) is
"never be afraid to specialize". It is often more effective to generalize from a
specific solution to a specific problem than to build the general answer first
and then specialize it.

Perhaps you could turn it around and recast this "use case" as defining the
framing problem which motivates SIMILE and then solve one or more of the
specific instances while paying attention to this wider motivation? As a framing
for SIMILE this use case "works for me", it covers a very large and important
problem space. As a use case it is a little too general for my personal tastes.

> 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.

> 3. A community approaches the library to store metadata about a collection
> where they currently possess XML metadata and an XML schema.

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

These examples are all heterogeneous in the weak sense that different
collections would have different schemas.

Is the use case intended to also cover situations where the same underlying
collections might want to be annotated by different communities using different
schemas? That is the same data is described in different schemas thereby raising
importance of mapping data between the schemas? This is the sort of capability
that seemed to come up in our own discussions of "community Arkive".

> 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.

Suggested alternative:

"5. Once a schema is registered with SIMILE it may be evolved by generation of
new schema versions with additional fields, removed fields or changed
constraints. It should be possible for SIMILE to maintain access to the instance
metadata through multiple schema versions allowing interoperability between
schema versions as well as between related schemas."

Dave

Received on Friday, 20 June 2003 11:54:16 UTC