- From: Gannon Dick <gannon_dick@yahoo.com>
- Date: Thu, 24 Dec 2015 20:29:03 +0000 (UTC)
- To: <public-lod@w3.org>, Frans Knibbe <frans.knibbe@geodan.nl>
Hi Frans, "a versioning scheme based on DCMI has a weak spot: the property for denoting temporal validity (dcterms:valid) is impractical to the point of being unusable." Well, sort of. If one is trying to rank temporal validity then one is trying to rank the negative pattern of the property. One has to wake a sleeping naughty boy or girl up to determine the naughtiness property. In another familiar case, in a Hospital patients are woken up at all hours to take medications - you can be just as ill at home, with uninterrupted sleep. This seems to me to be the same logical problem (post hoc ergo propter hoc). Santa Claus, et al. can do this sort of thing without waking up naughty boys and girls. An Artificial Intelligence which believes it can do what Santa Claus can do is quite unhinged, I think :) --Gannon -------------------------------------------- On Thu, 12/24/15, Frans Knibbe <frans.knibbe@geodan.nl> wrote: Subject: Temporal validity: alternative for dcterms:valid? To: public-lod@w3.org Date: Thursday, December 24, 2015, 9:57 AM Hello again,The DCMI Metadata Terms vocabulary seems to have all the basic ingredients for building a versioning mechanism in to a dataset (which is or should be a very common requirement). Objects in a dataset can have life spans (temporal validity), be versions (dcterms:hasVersion/dcterms:isVersionOf) of another resource and replace each other (dcterms:replaces/dcterms:isReplacedBy).But as Jeni Tennison has noted some time ago (see final section 'Unanswered Questions'), a versioning scheme based on DCMI has a weak spot: the property for denoting temporal validity (dcterms:valid) is impractical to the point of being unusable. Dcterms:valid only takes literals (rdfs:Literal) as value, which makes it hard to use it for practical expressions of time intervals. Time intervals should be compound objects that are based on useful datatypes. For instance, xsd:dateTime (for dates) or xsd:integer (for years or seconds (e.g. in UNIX time)) could be used in SPARQL queries to filter or order temporal data. In a versioned dataset queries like 'give me all changes between time T1 and time T2' or 'give me the state of the dataset at time T3' should be easy to create and to resolve. It seems to me that this requires proper and well supported data types. A text string notation for time intervals is recommended by DCMI: dcmi-period. It is easy and versatile enough, but the average triple store probably does not recognize this notation as temporal or numerical data. So I wonder if there is a good alternative for dcterms:valid somewhere that can be used to indicate temporal validity.I did find http://www.w3.org/ns/prov#invalidatedAtTime in PROV-O, which could be considered applicable, but a matching property to indicate the start of the time period of validity does not seem to exist in PROV-O. Also, its range is xsd:dateTime, which I think is too restrictive because the time needs to be known up to the level of seconds.Does this gap still need to be plugged? Or is the solution out there?Greetings,Frans
Received on Thursday, 24 December 2015 20:29:39 UTC