Re: How "valid" is to use a term marked as "unstable" for a data publisher/consumer?

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 <> a écrit :
> +Cc: Leigh Dodds, for old time's sake
> On 20 July 2016 at 09:45, Ghislain Atemezing
> <> 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
> 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
> but didn't complete
> the work. There may also be things we can reflect from the
> experience, as well as mechanisms in OWL and SKOS, that ought to be
> incorporated. On the side, for example, we recently added a
> "pending" area of the vocabulary (see
> 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, describes the
> status ('pending') of the term ClaimReview. Probably the
> most important thing that page does is point to the corresponding
> issue tracker entry at
> 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... 


Ghislain A. Atemezing, Ph.D
Web: <>
Twitter: @gatemezing
About Me: <>

Received on Wednesday, 20 July 2016 11:05:21 UTC