Handling fuzzy production time spans

[rtroncy]

We now create systematically time spans for production and we try to interpret and define those time spans, in terms of beginning and end, attaching them to centuries when possible. This slide gives a good account of the situation per museum.

We should better represent when the production time is uncertain. A typical word used in the record is circa. Using CIDOC-CRM, we can use the property ecrm:P79_beginning_is_qualified_by attached to the time span like in doremus.

As quality check, we should count the number of objects that do NOT have a timespan attached to the production and the number of objects that have a timespan but do not have a time:hasBeginning which means we do not know yet how to interpret those time spans.

We should get rid of the timespan https://data.silknow.org/timespan/null_null (present, e.g. in http://data.silknow.org/graph/paris-musees)

The following query is interesting as it enables to list all the timespans we have created for each museums (results):

SELECT distinct ?g ?ts
WHERE {
  GRAPH ?g {
    ?o a ecrm:E22_Man-Made_Object .
  }
  ?prod ecrm:P108_has_produced ?o .
  OPTIONAL { ?prod ecrm:P4_has_time-span ?ts }
}
ORDER BY ?ts

---

Sub tasks:

• [x] represent uncertainty
• [x] remove null-ish timespans
• [x] include EDTF labels
• [x] extend coverage of parsing

(last point is not including MAD, to be handled in #5)

[pasqLisena]

We should better represent when the production time is uncertain. A typical word used in the record is circa.

Regex used for uncertain dates:

https://github.com/silknow/converter/blob/863c03611a527048608720363b18973308849d82/src/main/java/org/silknow/converter/entities/Production.java#L15

To those cases, we may want to add "or later", "or earlier", "before" and "after".

Using CIDOC-CRM, we can use the property ecrm:P79_beginning_is_qualified_by attached to the time span like in doremus.

A big difference between DOREMUS and SILKNOW is in timespans sharing among different objects.

• In DOREMUS (apart centuries which are represented as E4 Periods, rather than TS), each TimeSpan is never shared between 2 events. In other words, if work A and work B have both been composed in 1823-1825, we will have 2 distinct time-spans, respectively linked to expression creation event A and expression creation event B. In this way, the eventual incertitude on A can be expressed independently from B (A uncertain, B certain), because we have 2 TS.
• In SILKNOW, the same time-span is shared across multiple production events. If we add an incertitude label to one of them (using ecrm:P79_beginning_is_qualified_by), we cannot then distinguish to which production it is related.

Possible solutions:

1. Separate the time spans (at least when we have incertitude) => Back to the DOREMUS case
2. Mark the incertitude directly in E12 Production, using ecrm:P79_beginning_is_qualified_by (improperly), P2 has type or any other annotating property
3. Get rid of TS in favour of a combination hutime:UncertainTimeInterval and time:ProperInterval. This gives also more flexibility with properties such as hasPossibleBeginning, hutime:hasReliableBeginning, etc. See also this paper. This solution also imply 1.
4. Use different properties for linking E12 Production to Time Spans, keeping P4 has time-span for certain dates. Unfortunately, I am not able to find appropriate properties. We could extend CIDOC with has uncertain time-span and (if needed) before time-span, after time-span, in or after time-span, in or before time-span (all sub-properties of P4)

[pasqLisena]

Timespans to be deleted:

• [x] https://data.silknow.org/timespan/null_null
• [x] https://data.silknow.org/timespan/n_d_
• [x] https://data.silknow.org/timespan/No
• [x] https://data.silknow.org/timespan/Desconocido
• [x] https://data.silknow.org/timespan/Desconocida

New cases to be parsed (among all unparsed ts ):

• [x] English months / seasons: January 1840, Fall_1917
• [x] 3-digits dates (so before 1000): 601 - 900, 150 aC, 500s CE, 700s, 700s 1100s
• [x] Trailing punctuation: 1855. , 1929 ,
• [x] Understand why are not parsed some cases like https://data.silknow.org/timespan/Seconda_meta_del_XIX_secolo or https://data.silknow.org/timespan/second_half_1100s, https://data.silknow.org/timespan/600s_800s
• [x] siglos_11_15, siglos_12_13, segles_10_11
• [x] or usually combine consecutive ts. Use the parts as start/end (e.g. 1920s_or_1930s)

Other

• [x] Add start-end dates to fourth century and fifth century
• [x] Fix interlinking of periods like Periodo_colonial, Fatimite_period, etc

How to deal with productions with different dates ? E.g. "Designed 1786; Woven 1787–91"

[rtroncy]

Thanks a lot @pasqLisena for this comprehensive investigation as well sketches of possible solutions. I also did more investigations. A relevant pointer, first, is https://www.loc.gov/standards/datetime/ (the so-called new EDTF format).

I search a lot in the LinkedArts community since they inherit from CIDOC-CRM practices. The LinkedArts suggested model for timespans is described at https://linked.art/model/base/#time-span-details. Read also:

• https://github.com/linked-art/linked.art/issues/218 (mostly)
• https://github.com/linked-art/linked.art/issues/302

At the moment, I'm hesitating between:

1. adopting the HuTime Ontology, https://arxiv.org/abs/1905.04611 (your solution 3)
2. staying the in the pure CIDOC-CRM world and creating different URIs when the timespan is uncertain (your solution 1) and make use of the properties P82a_begin_of_the_begin, P82b_end_of_the_end, P81_ongoing_throughout, P82_at_some_time_within, etc.

Thoughts?

[pasqLisena]

My thoughts:

• Using P82a_begin_of_the_begin, P82b_end_of_the_end, etc. will make us crazy when querying. I would keep the current start-end structure.
• EDTF is not RDF-compatible (at least yet). It would be nice to include it in our data somehow (do you have a property in mind to attach to TS?), but we will have no benefit in querying or visualising.
• Solution 1 is the more straightforward and avoid changes in queries (like in API and in the explorer). It is also easier for visualisation (just to read an additional textual field). EDTF can be used in the URIs production here (avoid collisions and automatic interlink)

[rtroncy]

OK, I also agree to keep the Solution 1 and to create "more" URIs identifying timespans, and basically a new URI each time we encounter a fuzzy timespan. I also agree to keep using the simpler start-end time of the timespan and to NOT use the newest P82a and P82b properties. I would use the EDTF notation in the label of the timespan.

[pasqLisena]

basically a new URI each time we encounter a fuzzy timespan

How do we create this? I think that we can use EDTF, or better a transposition of it in order to avoid special URI symbols (like ? or '/'). Examples

• http://data.silknow.org/timespan/1980_1981% (start in 1980, possibly end in 1981)
• http://data.silknow.org/timespan/1980%_1989% (around the '80s)
• http://data.silknow.org/timespan/1925%_1951% (2nd quarter of 20th century)
• http://data.silknow.org/timespan/..1984 (1984 or before)
• http://data.silknow.org/timespan/.._1984 (start unknown, end 1984)

Otherwise, we can return to UUIDs, using EDTF as seed. (but this would invalidate again the ts uris)

I would use the EDTF notation in the label of the timespan.

In this moment, we use skos:prefLabel ("clean" unique label) and ecrm:P78_is_identified_by (all encountered labels). https://data.silknow.org/timespan/1970_1979

I propose to keep these two and add a rdfs:label with EDTF.

[rtroncy]

I'm wondering if we could not have a mixed approach for generating URIs for timespans, namely:

• relatively transparent URI when timespans are certain (as it is done now, e.g. https://data.silknow.org/timespan/1970_1979)
• opaque URI when timespans are uncertain, therefore using a UUID for which the seed would indeed be based on the EDTF format).

The advantage of this solution is that a human would also immediately see whether it is certain or not by looking at the URI, but maybe this is over complicated to implement?

+1 for your labeling proposal for the timespan.

[pasqLisena]

The advantage of this solution is that a human would also immediately see whether it is certain or not by looking at the URI, but maybe this is over complicated to implement?

It's not complicated. I proceed to implement this