HCLSIG BioRDF Subgroup/Meetings/2007-08-27 Conference Call/UriNoteStatus
URI note - progress - JAR 2007-08-24
- I'm still busy with another project. I plan to report to BioRDF on Sept 10 or Sept 17, depending on which of those dates has a BioRDF telecon.
- Participation of a new set of thoughtful, intelligent voices on the list is most welcome.
- I still haven't connected with anyone on the TAG, and this is very frustrating. I have an appointment with Sandro on August 30 and we'll see how that goes.
- Very brief summary of my current analysis:
- RDF is a language, and using the term "term" instead of "identifier" or "URI" helps to evoke the correct requirements.
- Our advice may have to depend on both time horizon (now vs. later) and durability parameters (short-lived vs. long-lived terms). This idea is the only way I can think of to reconcile the TAG's free-wheeling, fragile recommendations with the needs of long-lived RDF such as one might find in a scholarly publication: the TAG is thinking about a living, highly dynamic, constantly maintained web, while the libraries and courts are thinking about growing archives of unchanging records.
- Public-interest criteria to use to evaluate any proposed advice:
- nonrepurposing - once defined, a term's meaning shouldn't incompatibly shift, either as a result of administrative accident or author revision.
- availability - it should be possible to find out what a term is (or was) supposed to mean
- clarity - definitions should be parsimonious and clear (this is a stylistic issue, not amenable to technical fixes) - punning is confusing
- nonredundancy - reuse existing terms when possible so as to promote 'joins' and reduce the need for concordances (probably no technical fix)
- distribution - no technical or administrative choke points
- generality - meaning of a term is not restricted to any particular domain or class
- likelihood of adoption by uncommitted HCLS members [added 8/25]
- ease of adoption [added 8/25]
- For example, DOIs may fail on point 6, while http: faces threats on points 1 and 2, and purls face a threat on point 5. (All of these particular problems can be fixed, but there is a story to tell in each case.)
- Some kind of little expert system will probably be needed for access to term definitions and so-called "representations". This might be client side or service based. Compare to the state of email in 1985, with sendmail as expert system. Since the ES configuration is what the "resolution ontology" idea is about, I need to understand why it has gotten so little traction.
- Personally I'm very frustrated by TAG recommendations. They seem shortsighted and naive, and probably a poor match to the expectations of scientists and scientific projects. This is why I need to connect with the TAG somehow; fighting this out in email will be acrimonious and inefficient.