Re: Evolving vocabularies

Since Gannon was kind enough to mention me by name I cannot hide in the 
shadows...

If I understand you correctly, Carsten, your vocabulary is a work in 
progress and you yourself are building the primary tool that uses it? If 
that's true then you're pretty much free to do whatever you want. Basic 
question, if you change something, what breaks? If it's only your 
system, well, go ahead.

If, however, you and others, are publishing data using your vocabulary 
then you need to be much more careful. I would say:

1. Once you've defined a class or property, don't change it, don't 
change the URI and don't delete it. Ever. (Minor clarifications are OK 
but basically that's it).

2. You can add new classes and properties any time you like and, since 
you control the namespace, you can do that whenever you like according 
to your own change control policy. That can be anything from "form a 
working group, have three conferences and then change it" through to 
(mentioning no names) "the editor of this document feels like changing 
something so it is hereby changed and you can take it or leave it."

3. Re-using existing vocabs helps you to avoid making more changes than 
may be necessary. For example - you're using Dublin Core a lot. Good. 
But I also see that, for example, you have defined this:

http://hxl.humanitarianresponse.info/ns-2012-06-14/#Country

That doesn't look so good. You have a URI with a version number in it, 
used to define something that a lot of people have already defined (see 
http://labs.mondeca.com/dataset/lov/search/#s=country). My guess is the 
the previous version of your vocab and the next one will all include the 
class of Country?

Cool URIs don't have version numbers (or technologies like .cgi? or 
.php? or .aspx?). Dan & Libby curse the day they included 0.1 in the 
FOAF namespace - it's still there even though the vocab has evolved. 
Through every version foaf:Person has meant 
http://xmlns.com/foaf/0.1/Person

However you execute 2, there may come a day when the legacy of 1 is too 
much of a burden and you really wish you could start again. *That's* 
when you might define a new namespace and go from there which is what 
Dublin Core did when they went from DC elements to dcterms. But those 
old element URIs still work.

You can deprecate terms in your vocab - i.e. tell people not to use them 
any more because they might disappear one day - but unless they're doing 
you actual harm, keep them there even if the advice is not to use them.

Back to what Gannon was talking about, yes ADMS should be useful for 
describing your vocabulary. The namespace doc for it is at 
http://www.w3.org/ns/adms and although it's only been there just over a 
month, it *has* changed a little (and includes a change log).

The idea of ADMS is to make it easy to find and perhaps aggregate things 
like taxonomies, code lists, specs and vocabularies. More at 
http://www.w3.org/QA/2012/06/implementing_adms_and_the_core.html

HTH

Phil.




On 27/06/2012 15:30, Gannon Dick wrote:
> Hi Dr. Kessler,
>
> Best Practices are emergent.  I think ADMS[1] (Phil Archer at the W3C) has it right philosophically, that is to group data about Assets in a generic Repository container.  Federalization, necessary to use the data, is an IT convention with little organizational governance value.  Oddly, building an empire turns out to be a terrible way to build an empire (or an ocean of data).
>
>
> My own work is pretty consistently off-center (I'll thank you all not to elaborate at length).  But when you do think in terms of a Repository as an abstract point of federalization, the coverage map of familiar organizations looks much different than a simple listing[2].  A "big picture" can be derived from Regional Data[3], but the process of building a bigger Repository results, results only in a bigger Repository.
> --Gannon
>
>
> [1] https://joinup.ec.europa.eu/elibrary/document/adms-enabled-federation-semantic-asset-repositories-brochure
> [2] http://www.rustprivacy.org/2012/cctld/psp/
> [3] http://www.rustprivacy.org/2012/roadmap/
>
>
> ________________________________
>   From: Carsten Keßler <carsten.kessler@uni-muenster.de>
> To: public-lod@w3.org
> Cc: Chad Hendrix <hendrix@un.org>; perrin.v@gmail.com
> Sent: Wednesday, June 27, 2012 3:11 AM
> Subject: Evolving vocabularies
>
> Dear LODers,
>
> I have already bugged this list with our Humanitarian eXchange Language project a couple times, and I'd like to hear your opinion on the following problem.
>
> We are constantly working on the vocabulary (see http://hxl.humanitarianresponse.info/ for the latest version), so it gets revised fairly often, sometimes several times a week. While we are doing that, we are also developing our tools around the vocabulary, and we have started producing some data (you can already query the endpoint at http://hxl.humanitarianresponse.info/sparql, although there is not much there yet).
>
> When we are producing data, we always use the latest version of the vocabulary; obviously, that will create problems over time, say if you want to query all Camps (http://hxl.humanitarianresponse.info/ns-2012-06-14/#Camp) out of the triple store, independent of the vocabulary version. So far, each version of the vocabulary is linked to the previous version via dc:replaces, but this does not really solve our problem.
>
> We are working towards a stable first "release" of the vocabulary at some point, but until then, we will have to work around this issue somehow. Is there any best practice for that kind of problem? Would it make sense to apply dc:replaces to every class/property that is carried over from a previous version?
>
> Cheers,
> Carsten
>
> ---
> http://carsten.io
>

-- 


Phil Archer
W3C eGovernment
http://www.w3.org/egov/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Wednesday, 27 June 2012 15:40:32 UTC