Very interesting discussion!
There's a perfectly useful "lom:status" property lurking in the IEEE
LOM/RDF drafts (range: lom:Status), and I believe this is a relatively
unproblematic property to specify, so I certainly support its addition
to the DCMI terms.
When it comes to the values of the property, I'm thinking that status
properties are most useful when they come in well-designed sets, i.e.
when they are connected to an explicit workflow model.
Attached is a simple such model for vocabulary terms that I designed
when we were talking about vocabulary persistence a while ago, showing
how a property can advance in two essential ways:
undefined -> experimental -> withdrawn
or
undefined -> experimental -> draft (-> stable) -> deprecated
This model assumes that once a property is in "draft" status, it cannot
be withdrawn, only deprecated (corresponding somewhat to Dan's
"archaic" I suppose).
Similarly, the status "DCMI Recommendation" also assumes an underlying
workflow as defined by DCMI.
So, I'd be careful with defining a "stable" status without *any*
reference to the workflow... On the other hand, a basic workflow can be
made inherent in the basic status value resource definitions.
Just a brain dump....
/Mikael
tis 2010-04-27 klockan 17:45 -0400 skrev Thomas Baker:
> On Tue, Apr 27, 2010 at 11:11:18PM +0200, Dan Brickley wrote:
> > Here's a thought - should the value of a useful 'status' property be
> > concepts on a SKOS thesaurus-like-thing? It would make simple hierarchy and
> > i18n of labels a bit easier, without getting overly ontological...
>
> That's what I was thinking, at least for DCMI-specific statuses
> such as "DCMI Recommendation", each with a URI. The bigger
> question is whether there would be much gain in trying to
> standardize a short list of statuses such as "deprecated".
> Views on status may be too diverse, and the requirements for
> conceptualizing status across different vocabularies too weak,
> to justify putting much effort into that, though status values
> identified by URI would at least be easy to align with, say,
> SKOS mapping properties.
>
> However, the idea of a "status" property -- Bernard's original
> suggestion -- might make sense.
>
> Tom
>
|