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

+Cc: Leigh Dodds, for old time's sake

On 20 July 2016 at 09:45, Ghislain Atemezing
<> wrote:
> Hi all,
> [ Apologize if this question has been answered before in this group. ]
> Recently, I was working on a project where we were just reusing existing
> terms for building a knowledge base for a private company. When we were
> considering using for example foaf:birthday, I was told by someone that it
> was marked “unstable” in the vocabulary file. The normal reaction would have
> been “so what?” ;)
> However I found the question somehow interesting in the sense that the vocab
> defining the term status of the vocabulary [1] uses“unstable” for all the
> properties in the vocabulary, and of course it is reused by many
> vocabularies [2]. At the meantime, FOAF is one of the most popular
> vocabulary used in the LOD cloud (stats for 2014 here [3] ) and I guess
> there are many data modeled with some of the terms flagged as “unstable”. I
> found an example dataset here for Nobel Prize [4].
> Is there any risk for data publishers or consumers (e.g., visual
> applications) to reuse “safely” terms flagged as “unstable”?
> Do you know any study on this type of questions?
> Any experience or thought is more than welcome to propose a more rationale answer to my project partner.

On some level this is my fault :)

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.

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.

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. 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. If you dig around
you'll see that was pretty much what we had in mind originally...



> Best,
> Ghislain
> [1]
> [2]
> [3]
> [4]
> ---------------------------------------
> Ghislain A. Atemezing, Ph.D
> Mail:
> Web:
> Twitter: @gatemezing
> About Me:

Received on Wednesday, 20 July 2016 10:11:30 UTC