- From: Ghislain Atemezing <auguste.atemezing@eurecom.fr>
- Date: Wed, 20 Jul 2016 13:04:49 +0200
- To: Dan Brickley <danbri@danbri.org>
- Cc: Leigh Dodds <leigh.dodds@gmail.com>, Libby Miller <libby@nicecupoftea.org>, W3C Vocabularies <public-vocabs@w3.org>, Linking Open Data <public-lod@w3.org>
- Message-Id: <CCEAFC0F-ABB2-48F1-A885-0B98269C7D09@eurecom.fr>
Hi Dan, Many thanks for this summary showing the beginning of what we can be proud to contribute as well. Many thanks for all your contributions I have to say. Few comments inline below… > Le 20 juil. 2016 à 12:10, Dan Brickley <danbri@danbri.org> a écrit : > > +Cc: Leigh Dodds, for old time's sake > > On 20 July 2016 at 09:45, Ghislain Atemezing > <auguste.atemezing@eurecom.fr> wrote: > > On some level this is my fault :) No one to blame ;) Hopefully many thinks have changed since 2003, and that’s a good sign of maturity for the entire SemWeb community ;). > > The vocabulary at [1] bubbled out of FOAF collaborations many years > ago, where we were keen to explore more fine-grained mechanisms for > term evolution than the previously dominant notion that versioning > happened at the vocabulary/namespace level. We had seen efforts like > Dublin Core get stuck because of a sense that changing any term's > documentation necessitated a revision to the schema's version number > (DC 1.0 -> DC 1.1), and I had also been responsible for somewhat naive > language in the 1998/1999 working drafts of the initial RDFS spec > which encouraged the notion that any changes to a schema should > require a new URL. > > See http://lists.foaf-project.org/pipermail/foaf-dev/2003-July/005462.html > for the initial design discussions in the FOAF project, ~2003. > > The reason that the vocab status vocabulary is itself marked as > unstable, is that we hoped to refine it in the light of experience, > and in particular to consider using URLs instead of well known > strings, to better support i18n/l18n and SKOS-style refinement. We did > make a sketch of a sketch of a W3C Note on this at > https://www.w3.org/2003/06/sw-vocab-status/note but didn't complete > the work. There may also be things we can reflect from the schema.org > experience, as well as mechanisms in OWL and SKOS, that ought to be > incorporated. On the schema.org side, for example, we recently added a > "pending" area of the vocabulary (see http://pending.schema.org/) > where drafts are shared; this is roughly like "unstable" but the word > "pending" is slightly less intimidating to potential users. > > The main point of marking a term 'unstable' is that if the term > maintainer does change it in the light of experience, they have an > excuse and can say "hey, don't blame us, we said there was some chance > we might change the definitions in light of experience". Beyond that, > I doubt there is much that can be formally encoded and potential users > are probably best advised to read actual human-oriented text and > discussions to understand any remaining open issues. > What you call here “in the light of experience”, how would you measure that? Is it like gathering evidence of use from the community? In your opinion, is there a moment or deadline for a maintainer to do a revision of the terms. For e.g., the maintainer can state that after XX years/months, if I don’t see any concrete evidence, I can flag the “unstable” terms to “deprecated”, etc. > For example, http://pending.schema.org/ClaimReview describes the > status ('pending') of the schema.org term ClaimReview. Probably the > most important thing that page does is point to the corresponding > issue tracker entry at > https://github.com/schemaorg/schemaorg/issues/1061 where you can ready > anything that is known in that vocabulary community about the maturity > or otherwise of the relevant term. I like the idea, but at the same time how do you engage the discussion with the rest of the community? Probably “pending” as you say is a good idea. > So if I were revisiting the > vocabulary status vocabulary in 2016 my advice would be that it should > be re-oriented towards discovery of such human-oriented documentation, > rather than trying to over-formalize codes like 'unstable' vs > 'testing' whose nuanced meaning will naturally vary by context and > project. You forgot to mention also in the revision to add more metadata in the vocab (for the machines as well) ;) There will be always a tradeoff between what is useful to be discovered by the machines and what can humans can support. I guess this will be more critical with the new technologies such as self driving cars and so on... Cheers, Ghislain --------------------------------------- Ghislain A. Atemezing, Ph.D Mail: ghislain.atemezing@gmail.com Web: https://w3id.org/people/gatemezing <http://www.atemezing.org/> Twitter: @gatemezing About Me: https://about.me/ghislain.atemezing <https://about.me/ghislain.atemezing>
Received on Wednesday, 20 July 2016 11:05:22 UTC