I'm converting codelists to SKOS (skos:ConceptScheme) that contain statements about validity of the individual concepts. There's a date when concept started to be valid (i.e., recommended for use) and there's a date when the concept will cease to be valid (i.e., it'll be no longer recommended for use).
I'm wondering how to express this in RDF. First idea that came to mind was to use dcterms:valid from Dublin Core Terms vocabulary. The definition of this property suggests that it can be used with a date range: "Date (often a range) of validity of a resource." This suggests to use it with xsd:duration and so that it can express only a relative interval how long is something valid. To describe when a thing started or ended to be valid another property needs to be used.
The second option I've considered is to use a combination of dcterms:issued the express a date when something became valid, and dcterms:valid for a date (xsd:date) when that thing stopped being valid and appropriate for use. I think this a better option (also xsd:date is probably more readable to users than xsd:duration).
Are there better ways for expressing validity of an RDF resource? What do you think is the best approach?
The low-tech version would be to remove or deprecate the concept once validity has expired, or to exploit versioning on a lower level. This option is often underrated in terms of versioning RDF.
Otherwise, I think that dcterms:valid makes sense, yes. Another option would be to create a new sub-property of dcterms:valid somewhere that narrows down the description and the range to what you need.
In terms of the range
-
xsd:duration is valid as a datatype, but its interpretation is not well supported by RDF tools (as @cygri pointed out to me once upon a time) since it is explicitly not supported in the RDF Semantics document or supported in OWL 2.
-
xsd:date is not supported in OWL 2 either.
- You could instead go for
xsd:dateTime as the best option supported by RDF and OWL 2, but due to optional timezones, values for this datatype don't have a total ordering because you cannot always tell what specific time instant a date-time literal refers to.
-
xsd:dateTimeStamp resolves the previous issues with xsd:dateTime, but is not yet recognised in various RDF standards/tools.
So yep, datatypes suck. In summary, I would avoid xsd:duration, and probably go with xsd:date as the simplest/most readable solution.
It sounds like you need :validFrom and :validUntil (or :validTo, or :expires). I would not use dctterms:valid to store a date when information stops being valid. From reading description of this property I think such use would be counter-intuitive. Then again, dcterms:valid (and Dublin Core in general) is very loosely defined. The content can literally be anything you want it to be. This deceives the purpose of using an established common vocabulary in the first place.
There is work going in W3C on Provenance Vocabulary. It is not unreasonable to expect something like this to be covered as provenance. But the working group didn't yet deliver the vocabulary and existing published vocabularies they are taking as input (for example, http://trdf.sourceforge.net/provenance/ns.html) do not support your use case. In the meantime, I would simply create my own properties and make their range be xsd:date or whatever works for you.
There is a 7 year old discussion about the way to use dctterms:valid: http://lists.w3.org/Archives/Public/public-esw-thes/2004Oct/0064.html. I did not see anything more recent than that.