How to properly store a period without a known begin date or end date?

[mrivoal]

Currently, when a date is selected as a period in the GUI, the user has to provide a begin and end date to enter this data as a proper period.

If he doesn't provide at least a year for the begin date, the year 1 is assumed. On the other hand, if he doesn't provide a year for end date, the current year is assumed and stored in Knora.

At some point, shouldn't we provide a more realistic scenario to handle complex dates (uncertainty, inaccuracy) in humanities, e.g. let the user record a period with an unknown begin date or end date ? Because, if we assume the value or the missing information, it could be confusing in the event of a timeline visualisation, for example.

I am currently facing this problem with an ontology and I will have to split the period into 2 different dates, which is not completely satisfying.

What do you think?

[tobiasschweizer]

Just to clarify: the GUI is SALSAH 1.5?

So then this would be a problem of how the GUI component generates the date string to be submitted to Knora.

[benjamingeer]

It sounds like you don't want to describe a period, but rather the beginning or end of a period. In that case, you can use a period in which both dates are the same. This is understood to be a single date.

[tobiasschweizer]

e.g. let the user record a period with an unknown begin date or end date ?

like terminus post / ante quem?

[mrivoal]

Yes, the GUI is Salsah 1.5.

[mrivoal]

It sounds like you don't want to describe a period, but rather the beginning or end of a period. In that case, you can use a period in which both dates are the same. This is understood to be a single date.

No, you know it is period not a single date. What if you want to store the dates of life of someone for which you know the death date but not the birth date? His life is still a period even if you can't record it as such.

[mrivoal]

like terminus post / ante quem?

That would be great, yes.

But even if we don't go that far, doesn't leaving the begin date blank would make more sense than assuming it is year 1?

[mrivoal]

It is not urgent at all but I think we should somehow have this in mind, as the representation of time is a real challenge in humanities.

[mrivoal]

I don't know if we should go as far as Heurist, but it could be inspiring to see how this tool handles dates.

[benjamingeer]

No, you know it is period not a single date.

I'm saying that you can't store information that you don't have. If all you have is one date, you don't have a period to store (even though it might have existed in reality).

His life is still a period even if you can't record it as such.

Why not have separate birth and death dates, and make both of them optional?

Keep in mind that we need to be able to compare dates. Given any two Knora dates, we need to be able to say whether they are equal, i.e. whether they overlap. Suppose you have someone's birth date but not their death date. Should we store the death date as infinity? That would mean that the person's lifetime would be equal to every date after their birth, forever, which is probably not what you want.

I think the only answer that makes sense is to store birth and death as two separate dates. Then you can also model the uncertainty in each one, using a range.

doesn't leaving the begin date blank would make more sense

In Knora, the way to do that is to make the start and end dates the same. It means that you have only one date, not two: https://docs.knora.org/paradox/02-knora-ontologies/knora-base.html#datevalue

I don't know if we should go as far as Heurist, but it could be inspiring to see how this tool handles dates.

If you use a probability curve, what happens when you do a search like, "find me all the events that occurred before this date"? Do the search results include probabilities?

[mrivoal]

Why not have separate birth and death dates, and make both of them optional?

Yes, that is what I am going to do.

Suppose you have someone's birth date but not their death date. Should we store the death date as infinity?

This is when terminus post quem and termines ante quem would be useful.

If you use a probability curve, what happens when you do a search like, "find me all the events that occurred before this date"? Do the search results include probabilities?

This probabilty curve doesn't talk to me much and I see your point.

But if a GUI could allow the user to give more information about a date (simple date vs. approximate date with a range, period with probable TPQ & TAQ), how should it be stored in Knora? Only through a project-specific ontology as you suggest or should the knora-base ontology at some point provides the means to store complex date so that a generic GUI could handle them properly?

I think I prefer the latter.

[benjamingeer]

But if a GUI could allow the user to give more information about a date (simple date vs. approximate date with a range, period with probable TPQ & TAQ), how should it be stored in Knora?

Knora can already store these:

• simple date has identical start and end dates with day precision
• if there is uncertainty, the start and end dates are different and/or have month or year precision

If you want to annotate the meaning of a date (TPQ/TAQ), that could be done with a project-specific ontology for now, which we could eventually standardise based on consensus among projects.

[benjamingeer]

Maybe we should advise people not to use a single DateValue to represent a period, and instead to use it only to represent a single date (approximate or not), and to use two DateValues to represent a period. @lrosenth what do you think?

[benjamingeer]

@lrosenth As far as I remember, the reason why a DateValue contains two dates is so it can represent an approximate date as a range from "earliest possible" to "latest possible". If people also use it to represent an actual period with a precise start and end, it seems to me that this introduces an ambiguity in the repository which could be a problem for data reuse. How would you know if a given DateValue represented an approximate single date or a real period?

[lrosenth]

Yes, that is a very good point! Semantically spoken these are separate cases. I think Your proposition to advice people (like me :-) to use 2 DateValues for indicating a period is correct and I fully support it.

[mrivoal]

As far as I remember, the reason why a DateValue contains two dates is so it can represent an approximate date as a range from "earliest possible" to "latest possible".

I had no idea about it and I think Salsah 1.5 induces/induced people in error by giving the possibility to record a DateValue as a period.

Maybe your point should be made clearer in Knora doc and in Knora ontology as well that a period should be represented with two different DateValue.

[subotic]

Anything speaking against adding a PeriodValue to knora-base?

[benjamingeer]

Anything speaking against adding a PeriodValue to knora-base?

Adding a new value type is a lot of work. Since a period value type would just be two date values, both optional, it would look very much like a Period resource class, which would be easier to implement.

[lrosenth]

I go with Ben on this issue. A period can be modelled easily using to date values. As the lifespan of a human: birth and death. Both may indeed have some incertainty...

Lukas

Sent from my iPad

On 20 Sep 2019, at 21:02, Benjamin Geer notifications@github.com<mailto:notifications@github.com> wrote:

Anything speaking against adding a PeriodValue to knora-base?

Adding a new value type is a lot of work. Since a period value type would just be two date values, both optional, it would look very much like a Period resource class, which would be easier to implement.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/dhlab-basel/Knora/issues/1443?email_source=notifications&email_token=ABJX3THZPTLLGB7QMJL33ADQKUM5LA5CNFSM4IYLFEX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7HTOJY#issuecomment-533673767, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABJX3TGY37LRMYOLAFQGPFDQKUM5LANCNFSM4IYLFEXQ.

[subotic]

Would it make sense to have something in between a Resource and a Value? Something like a “complex” value, consisting of one or more “simple” values?

However it is implemented, it would be good to have it sooner then later, so that we provide an official way of encoding periods. Over time, we can always extend it.

[benjamingeer]

Would it make sense to have something in between a Resource and a Value? Something like a “complex” value, consisting of one or more “simple” values?

Why not just use a resource?

[benjamingeer]

Resource is a recursive data structure. If you need a tree structure, with values as the leaves, you can always use resources for the non-leaf nodes. It’s designed like that.

[lrosenth]

Complexity: I want to search for all humans that are alive 1985: which means birth < 1985 and deth > 1985... Having the Period as Resource, this becomes complicated (not impossible...). Let me think over it and have next week a short skype about it...

Sent from my iPad

On 21 Sep 2019, at 10:35, Benjamin Geer notifications@github.com<mailto:notifications@github.com> wrote:

Would it make sense to have something in between a Resource and a Value? Something like a “complex” value, consisting of one or more “simple” values?

Why not just use a resource?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/dhlab-basel/Knora/issues/1443?email_source=notifications&email_token=ABJX3TD3AQIAVZ3ZFDAHSMDQKXMGPA5CNFSM4IYLFEX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7INM5A#issuecomment-533780084, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABJX3TDEOZKRH6Q2TGNLSUDQKXMGPANCNFSM4IYLFEXQ.

[benjamingeer]

I want to search for all humans that are alive 1985: which means birth < 1985 and deth > 1985... Having the Period as Resource, this becomes complicated

It would be easy in Gravsearch. And I don’t see how adding a “pseudo-resource” would make it simpler. The triples (and therefore the query) would be the same.

[lrosenth]

Ok, I see. Then we can probably just make a recommendation - or, if it makes sense - add a resource class to knora-base (such as the linking resource) from which project specific periods can be derived...

Von meinem iPhone gesendet

Am 21.09.2019 um 11:25 schrieb Benjamin Geer notifications@github.com:



I want to search for all humans that are alive 1985: which means birth < 1985 and deth > 1985... Having the Period as Resource, this becomes complicated

It would be easy in Gravsearch. And I don’t see how adding a “pseudo-resource” would make it simpler. The triples (and therefore the query) would be the same.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/dhlab-basel/Knora/issues/1443?email_source=notifications&email_token=ABJX3TGUUGVIKFUF2AUEABTQKXSCJA5CNFSM4IYLFEX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7IOE7A#issuecomment-533783164, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABJX3TCUUNYW4ZJUSSFUWKLQKXSCJANCNFSM4IYLFEXQ.

[mrivoal]

I would see 2 objections to make a period a new resource in knora-base.

• if it is a new resource, how will it be displayed in the GUI? If it like for any other resource linked to another, then the user will have to open a new window just to enter a period. Not very user friendly to enter data (unless at some point the notion of "compound resource" is introduced both in Knora and in the GUI, as suggested here or here). I agree with Lukas that retrieving period information would be more complicated for the user (no GUI for this feature at the moment).

• if we add a period as a new common resource, I don't think it should be added to knora-base ontology. From my point of view, it would a first step toward a standardized ontology of shared concepts for Knora, like place, event, etc.

[benjamingeer]

if it is a new resource, how will it be displayed in the GUI?

If it's your GUI, you can display it however you want. :)

And perhaps there could be a Knora-ui component for it.

[mrivoal]

if it is a new resource, how will it be displayed in the GUI?

If it's your GUI, you can display it however you want. :)

Yes, I know. But I am always talking in the most GUI-generic way, with KUIRL or Salsah in mind.

[benjamingeer]

From my point of view, it would a first step toward a standardized ontology of shared concepts for Knora, like place, event, etc.

I think it would be great if you could make a draft of such an ontology, based on your experience with different projects. Then we could think about how to make GUI components for it.

[mrivoal]

Let's say that I (or even better we) could begin to work on this once the project metadata ontology issue is closed :)

Then we could think about how to make GUI components for it.

If this means less open windows in the GUI and an easier expression of complex cross-resources queries, it would be really useful.