creation dates don't have datatype

[VladimirAlexiev]

The structured creation dates DateBegin DateEnd should have a datatype (in this case xsd:gYear). If other museums provide greater resolution, they should use xsd:gYearMonth or xsd:date respectively. Such datatypes are needed for efficient comparison (so the repo knows to index them properly).

Note: the Creation date mapping doesn't specify datatypes for earliest_date latest_date.

[workergnome]

It's definitely a limitation of the review tool that there's not an easy way to specify types for literals.

I think it's worth having a discussion of how to apply data types to dates—they definitely need them, and they're currently a mess. I know @azaroth42 suggested that everything should be a xsd:dateTime regardless, and I've been trying to figure out how to record variant precisions of dates using CIDOC-CRM, xsd, and/or EDTF.

[VladimirAlexiev]

This decision should be in line with what repos support.

• No repos implement other than XSD types (AFAIK)
• SPARQL 1.1 only mandates xsd:dateTime comparisons
• many repos (eg GraphDB) also implement xsd:date comparisons.

So you could represent it eg like this:

<date1> a crm:E52_Time-Span;
  rdfs:label "2017";
  crm:P82a_begin_of_the_begin "2017-01-01"^^xsd:date;
  crm:P82b_end_of_the_end     "2017-12-31"^^xsd:date.

<date2> a crm:E52_Time-Span;
  rdfs:label "Feb 2017";
  crm:P82a_begin_of_the_begin "2017-02-01"^^xsd:date;
  crm:P82b_end_of_the_end     "2017-02-28"^^xsd:date.

<date2> a crm:E52_Time-Span;
  rdfs:label "between May 2016 and Feb 2017";
  crm:P82a_begin_of_the_begin "2016-05-01"^^xsd:date;
  crm:P82b_end_of_the_end     "2017-02-28"^^xsd:date.

Of course, the latest date must be an accurate end-day of the respective month.

[VladimirAlexiev]

@caknoblock can you comment what is supported by the repository

[caknoblock]

We are running Apache Jena Fuseki 2 for the triplestore.

On Mar 2, 2017, at 1:48 AM, Vladimir Alexiev notifications@github.com wrote:

@caknoblock https://github.com/caknoblock can you comment what is supported by the repository

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/american-art/cbm/issues/64#issuecomment-283606590, or mute the thread https://github.com/notifications/unsubscribe-auth/ABB-qeViN-cENks0kAVy_M2ntzdqC72Aks5rhpBegaJpZM4ML7we.

{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/american-art/cbm","title":"american-art/cbm","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/american-art/cbm"}},"updates":{"snippets":[{"icon":"PERSON","message":"@VladimirAlexiev in #64: @caknoblock can you comment what is supported by the repository"}],"action":{"name":"View Issue","url":"https://github.com/american-art/cbm/issues/64#issuecomment-283606590"}}}

[VladimirAlexiev]

And do you know which date-related datatypes it supports for efficient comparability? Sparql only mandates comparability of full xsd:dateTime: https://www.w3.org/TR/sparql11-query/#OperatorMapping.

Of course, the XSD format is such that years 0001 to 9999 will compare correctly even if string comparison is used. But it may not be as efficient as having a special literal index.

[bsnikhila]

Changed them to xsd:date.