 |
 |
Hi Bernard, On Tue, Apr 27, 2010 at 08:21:22PM +0200, Bernard Vatant wrote: > Thanks for the historical background but I think you missed my point > altogether, sorry I was not clear. I was not speaking about status *of* DCMI > terms, but of having a property defined in DCMI namespace such as > *dcterms:status* :) I understood your requirement to be that of saying that certain terms in your Geonames ontology need to have a status of quasi-obsolescence (i.e. quasi-deprecated) -- status *of* Geonames terms. And I thought you were surprised because we didn't have a property in a DCMI namespace to express the relation between such a term and its status (and by analogy, of a DCMI term to a status). My reply, in essence, said that we have long had a notion of _document_ status (e.g., "DCMI Recommendation") but that we never formalized that as an RDF property, nor did we extend the notion of status to individual terms -- actually two separate issues -- though perhaps we should. Perhaps the point is that we did not apply metadata recursively to the description of the specification documents, in which case we would have needed to coin a property for status. I believe that was actually on our radar screen at one point but not as a priority. Would you like to propose one? It does seem like an obvious gap... Tom > > Cheers > > Bernard > > 2010/4/27 Thomas Baker <[log in to unmask]> > > > On Tue, Apr 27, 2010 at 06:56:04PM +0200, Bernard Vatant wrote: > > > We are currently revisiting the Geonames ontology (long overdue) > > including > > > feature codes, on which I would like to add some Dublin-Core like > > > annotations re. concepts. In particular some concepts are going to be > > > deprecated using dcterms:isReplacedBy, some will be deprecated altogether > > > without replace because they've never be used, and quite a lot will be > > put > > > in a status of quasi-obsolescence or quasi-extinction. Those are feature > > > codes used less than one per million features, which means less than 7 > > times > > > considering Geonames has over 7 millions features in store ... > > > I was wondering which vocabulary is the best for expressing that. > > > http://www.w3.org/2003/06/sw-vocab-status/ns is used by FOAF, > > Bibontology > > > and others. But it defines status as a data property, I would prefer an > > > object property with an enumerated range of individual values. > > > > Yes, I see advantages to that. > > > > > Of course > > I > > > can define those in geonames data space, but since this is not particular > > to > > > geographical codes, I was wondering if there was some vocabulary on some > > > shelves I miss. BTW I was amazed not to find any "status" property in > > Dublin > > > Core. > > > > Historically, DCMI Metadata Terms began as a series of > > documents (an RFC [1], then a DCMI Web page), and those > > documents had status as documents - e.g., "informational" > > as defined by IETF [1], "DCMI Recommendation" for [2]). > > This information was not expressed in the corresponding RDF > > schemas (e.g., [3]). > > > > Properties and classes officially came into being > > and were assigned URIs when they were published in a "DCMI > > Recommendation" document -- i.e., they effectively derived > > their "status" from the status of the Web document in which > > they were published. The DCMI Namespace Policy namespace > > policy [5], then, made persistence guarantees for URIs, once > > declared, but without providing for lesser statuses, such as > > "deprecated". > > > > DCMI Metadata Terms never followed the style of FOAF (and > > other vocabularies) of coining experimental terms, giving > > them progressively higher status as they were implemented, > > and eventually possibly deprecating them -- the terms either > > existed (and were "recommended") or not. > > > > DCMI invented its process year by year, and if emerging good > > practice now dictates that it is good to assign status to > > individual terms, I should think we'd want to help standardize > > such a status vocabulary, whether in a DCMI namespace or > > elsewhere. > > > > Tom > > > > [1] http://www.ietf.org/rfc/rfc2413.txt > > [2] http://dublincore.org/documents/2000/07/11/dcmes-qualifiers/ > > [3] http://dublincore.org/2001/08/14/dces > > [4] http://dublincore.org/documents/dcmi-namespace/ > > [5] http://dublincore.org/documents/2001/10/26/dcmi-namespace/ > > > > -- > > Thomas Baker <[log in to unmask]> > > > > > > -- > Bernard Vatant > Senior Consultant > Vocabulary & Data Engineering > Tel: +33 (0) 971 488 459 > Mail: [log in to unmask] > ---------------------------------------------------- > Mondeca > 3, cité Nollez 75018 Paris France > Web: http://www.mondeca.com > Blog: http://mondeca.wordpress.com > ---------------------------------------------------- -- Thomas Baker <[log in to unmask]>