Goal of this repository

[ktk]

Let's get some ideas on what we could do here. From my POV:

• Have a place where groups interested in EDTF-related time formats & RDF can discuss & share know-how.
• Provide code and/or references to code that helps convert various time formats to EDTF or vice versa
• Have a place to talk about OWL time in the context of EDTF, provide examples of mapping.
• Talk about integrating/using EDTF & OWL Time in SPARQL

We might use the new GitHub discussion feature for that, I think issues might be a bit too formal in the beginning at least. (moved)

[rybesh]

Have a place where groups interested in EDTF-related time formats & RDF can discuss & share know-how.

Absolutely. I’ve never used GitHub Discussions before, but it seems suited for that.

Provide code and/or references to code that helps convert various time formats to EDTF or vice versa

Probably references to code, since putting a bunch of loosely related code in one repo could get unwieldy.

Have a place to talk about OWL time in the context of EDTF, provide examples of mapping.

Yes. I would go further and say not just examples of mapping, but trying to build some consensus on standards ways of translating EDTF expressions to “expanded” representations modeled using OWL-Time (and possibly CIDOC CRM as well, though I would want to start with OWL-Time).

Talk about integrating/using EDTF & OWL Time in SPARQL.

Yes. This might also involve some discussion of how to implement rules for translating back and forth between EDTF literals and “expanded” triple sets, so that data using EDTF literals can be queried over using non-EDTF-aware SPARQL engines (and then “compressed” back to EDTF if necessary for export as e.g. CSV). Something like N3 entailment rules seem suited for this, but I’m not an expert in this area.

[rybesh]

After spending some time the past few weeks exploring how one might model EDTF using the Time Ontology, I think I have a better sense of what I would like to use this repo for. From the updated README:

This repository is for discussion and development of standards, best practices, and tools for using Extended Date/Time Format (EDTF) in RDF and OWL.

Currently it contains:

• A draft ontology extending the Time Ontology to model EDTF concepts

• A set of Turtle files using this ontology to model the different examples from the EDTF specification for EDTF level 0, level 1, and level 2.

Initially we just hope to reach consensus on how EDTF maps onto the Time Ontology.

Future work may include:

• Rules for automatically inferring Time Ontology constructs from EDTF strings

• Standards for linking datatypes to such rules so that non-EDTF aware tools can process EDTF (see David Booth's speculation about “rich literals”)

• Mapping to other temporal ontologies such as CIDOC-CRM

[vajlex]

excellent way to move forward on practical methods!
so far, in considering the EDTF items you have reviewed here, I wondered how they apply to the cases that I have worked with in historical/temporal gazetteers. Of course, you can provide for all sorts of useful mechanisms to treat dates and model them, but I wonder if there is any consensus on what we are really looking at with named places / toponyms and their temporal attributes? For CHGIS / TGAZ there was a concrete mapping of changes in placename (and some other attributes) in time, and this had the outcome of requiring very complex relationship mapping between objects when they changed. In the long run, I wonder if something simpler is needed, such as:
a. Primary source date (for example a year in ISO 8601), ie. the date of the text or map with primary evidence of the placename existing
b. Earliest known date (updated when other sources provide evidence of the name existing)
c. Event date [multiple] (to provide historical context for the place, a way to hook events to the place)

(btw, these dates would fit into the EDTF types of a. & b. open end, c. specific day with certainty/uncertainty)

It's a basic gazetteer item, here, and doesn't take into account any jurisdictions, containership, administrative functions or status, etc. but having tried to deal with all those in the past, I am of the opinion that simpler to model is going to last longer, if the core concepts are instantiated in the model.

just two cents.

[rybesh]

Hi Lex! I agree completely that simpler models are to be preferred to more complex ones, and I think that EDTF level 3 gets more complex than is necessary.

I also agree with your sketch of what is needed for toponyms. In PeriodO and in most of the placename gazetteer projects, people seem to be doing fine with some variation of earliest-start / latest-start / earliest-end / latest-end (with only the first of these required).

That said, I can see the value of some of the other EDTF constructs for documents or artifacts with dating info that has been corrupted in some way; e.g. an invoice dated 1908/[smudged]/9, where it’s either some day in September 1908, or the 9th of some month in 1908.

My main motivation for working on this is that EDTF is starting to be adopted and implemented in library and museum systems (see [1][2][3] for some examples), and sooner or later it will start showing up in RDF literals, and I’d like to have a way to deal with it and make it interoperable with other forms of date-time modeling.

[1] Islandora/controlled_access_terms#68
[2] https://github.com/duke-libraries/edtf-humanize/tree/master#readme
[3] https://github.com/sfomuseum/go-sfomuseum-edtf#readme