Dates and times (especially incomplete)

[JervenBolleman]

Subsection Dates in the Literals section says that "In the case that the time is not precisely known, we recommend using the first valid value for the fields that are not known, i.e. the value '01' for days and months, the value '00' for hours, minutes and seconds."

I don't think that is wise, as this introduces confusion between an exact known date time and a value known to precise time interval.

I think that this section should select on of these two possible solutions when an exact xsd:dateTime is not known.

• Use the TimeOntology to bracket the interval i.e. released after 2000 and before 2014.
• Use xsd:gYear, xsd:gYearMonth or xsd:Date

In any case I don't think as semantic web people we should ever encourage people to insert known falsehoods to suggest a known to a lower precision truth.

[AlasdairGray]

Jerven I completely agree with you here. Unfortunately for some of the predicates that we recommend, viz pav:createdOn, pav:authoredOn and pav:curatedOn, the data type is set to xsd:dateTime. For these we are tied to the approach that is suggested.

However, for the dct:created and dct:issued we could adopt the same approach as DCAT, which is as you suggest, use the appropriate shortened xsd, using the following text

rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string and typed using the appropriate XML Schema datatype [xmlschema-2]

[JervenBolleman]

I think if pav is that way we need to convince the pav maintainers to change this or replace those predicates. I don't think we should recommend this solution at all as it really is a bad practice.

Having two suggested ways of dealing with incomplete dates depending on the source ontology is confusing and I do not think that is a good solution to the problem.

[AlasdairGray]

There are various practical ramifications to using xsd date types or the time ontology when it comes to querying the data.

We propose to investigate how a few triplestores operate of various date types.

We will also look into the discussion around DCAT on this issue as they changed from a similar recommendation to the xsd date types. See discussion here http://lists.w3.org/Archives/Public/public-gld-wg/2012Jan/0010.html

[micheldumontier]

I'm worried about the practical consequences of having different XSD datatypes for an attribute, particularly in terms of SPARQL queries. We should probably create a small dataset to see whether triple stores adequately treat this.

[AlasdairGray]

If triplestores have implemented the xsd types correctly, then they should inherit from each other. But it sounds like there are differences in implementing these

[micheldumontier]

i think we should make sure :)

[JervenBolleman]

For range queries owlim work correctly but only for loaded data. Not for this bind example You don't need to load data.

SELECT *
WHERE
{
    BIND(("2005"^^xsd:gYear) AS ?date)
    BIND((?date > "2000-01-01"^^xsd:date) AS ?after2000)
    BIND((?date < "2004-01-01"^^xsd:date) AS ?before4000)
}

[JervenBolleman]

Jena does not seem to support this

[micheldumontier]

jerven, what happens if you query from 2005-04 to 2006-01 when given 2005?

Michel Dumontier Associate Professor of Medicine (Biomedical Informatics), Stanford University Chair, W3C Semantic Web for Health Care and the Life Sciences Interest Group http://dumontierlab.com

On Mon, Apr 28, 2014 at 8:57 AM, JervenBolleman notifications@github.comwrote:

Jena does not seem to support this

— Reply to this email directly or view it on GitHubhttps://github.com/joejimbo/HCLSDatasetDescriptions/issues/62#issuecomment-41576203 .

[AlasdairGray]

I propose that for this issue we adopt the same approach as DCAT, viz we set the range of date related properties to

rdfs:Literal encoded using the relevant ISO 8601 Date and Time compliant string and typed using the appropriate XML Schema datatype [xmlschema-2]

We could extend this by strongly encouraging the use of xsd:dateTime and have the validator throw a warning if a different data type is used.

See http://www.w3.org/2011/gld/track/issues/3 for details.

In particularly, it is not practical for us to insist on everyone conforming to xsd:dateTime since there will be very legitimate cases where some element is not known. Equally, the current proposal is very questionable since we require people to put in false data with no way of stating that it is false.

[AlasdairGray]

Extend guidance notes on dates to explain the various use cases