Comments about the Ontology Provider Guide

This document summarizes the most important issues in the Ontology Provider Guide

SKOS, RDF or OWL

-[John 20070205] why are we selecting these. Do we have more choices ?

-[John 20070205] Should we leave SKOS and OWL or only one of them ?

Versioning

  • [John 20070205] Why do you like YYYY/MM instead of YYYYMM? It enhances readability and limits ambiguity I guess. But it gets ugly if you need to add DD and more. My suggestion is YYYY/MM[/DD[/hhmm[ss]]] (brackets indicate optional components) - [Simon 20070219] Suggest using a more ISO 8601 representation for dates in the URI composition - [Luis 20070226] Let's use YYYYMM

Object Types and Mapping

  • [John 20070205] How will people take to the phrase "my project ontology at MMI"? And is the "CF Standard Variable Names at MMI" different than the "CF Standard Variable Names at CF"?
  • [John 20070205] This is confusing. Our recommendation above was that they all should have their own upper ontology. Now we say they should reuse our upper ontology. What is the expected/ideal model for distributed vocabulary services and ontologies?

File Extensions

  • [John 20070205] We could ask that RDF and OWL be officially recognized mime types, couldn't we?
  • We have the option of creating (registering for) a shorter name that we could use as the URL for our services. For just one example, mmireg.org and mmiserv are available (or more generically, metareg, mdreg, ontreg, ontserv). Given how often it will be used, being terse seems advantageous. (We could still route the requests to the same computer as now, of course.)

URIs VS URNs

  • [Simon 20070209] The arguments for and against URI schemes other than URL (sometimes known as "http URI") are complex. I am not convinced that the argument for always preferring URLs is watertight. For example 1. URLs go stale, as organizations change and their DNS entries follow 2. http-URIs imply resolvability, and this is not always necessary or even necessarily desirable, even for "web resources". I have discussed some of the issues here: https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/WebIdentifiers
  • [Luis 20070226] The main concern is the lookup service. If we have a clear simple service to allow query and retrieval of URIs we will not need URLs. I agree that URLs implies resolvability and that the primary purpose of a URI (in this context) is identification.