rduerr
commented
8 years ago Actually, I think there are several use cases embedded within that:
- The actual marine_biogeography use case itself
- Use of the ESIP ontology repository as a place to test updates/new versions of an ontology
- Annotation of ontology changes as a best practice to be supported or enforced by the repository
- The ability for repository resources to reference resources in other types of repository system (e.g., the MMI repository) - this is often harder than you'd think
lewismc
I'm not deeply entrenched in the STC activity yet, so I'm not sure how tightly controlled you want things in the developing document. Here's a use case we are pursuing with the ESIP COR resource.
I posted http://cor.esipfed.org/ont/?uri=http://mmisw.org/ont/ioos/marine_biogeography. That's a re-host of an ontology from MMI that we have describing the terms used in integrating data for the Ocean Biogeographic Information System of the USA (OBIS-USA). Most of the properties in that schema come from the Darwin Core and a few from other sources. Somewhere in this body of work, it might be useful to capture specific use scenarios to augment or demonstrate the abstract use cases captured in section 4 of the use cases and requirements document.
For instance, for use case 4.3, in the Marine Biogeography (MBG) data schema, expressed as an ontology in the Marine Metadata Interoperability Ontology Registry and Repository, we need to add additional technical definition to the properties in order to facilitate data integration algorithm development. Properties need explicit constraints in terms of data type and required formatting (e.g., ISO8601 dates) that are currently only implicit in property definitions. A community ontology repository can serve as a working testbed for new versions of the MBG ontology being used in live software development. In addition to versioning that is mentioned in the current draft, annotation is also an important feature to aid a potentially distributed group of developers in contributing versions of the ontology and testing them in heterogenous development environments. These could likely be handled through simple source control methods supporting the registry.