Issue about P82 and P81 usage

29 views
Skip to first unread message

Jean-Baptiste Pressac

unread,
Mar 16, 2016, 6:49:13 AM3/16/16
to Erlangen CRM
Hello,
I am working with two researchers on a prosopographic database of people who contributed to literature in Breton, a Celtic language of Bretagne (France) and I am interested to use the CIDOC-CRM (in particular Erlangen-CRM) to share our data in RDF format.

The database stores informations like the dates of birth, death, participation to groups of all kinds, studies... Informations where fuzzy times are legion. I read the PDF document How to implement CRM Time in RDF (response to issue 164 of CIDOC-CRM) but I need to clarify the use of P81a, P81b, P82a and P82b by examples.

If I understood well, P82 and P81 are durations, not dates. P82 is for the longuest known duration and P81 for the shortest known duration. Of course, it's impossible to determine the exact time at wich an historic event occured. Durations I guess are generaly reflecting a common understanding, not precise time-laps. Thus, while we could determine the exact time to the split second at which a space shuttle was lauched, it should be more difficult to determine with the same precision the end of the space mission (the exact second when the fist part of the landing shuttle touches the ground ?).

So, I understood that any "date" is considered as a duration in the CRM. Even a birth occurring on 25Th of July 1815 should be considered as an event occurring between for instance 25-7-1815 at 0:00 and 25-7-1815 at 24:59. But in that case, what could be the values of P81a, P81b, P82a and P82b ? If we don't take the hours and minutes into account, should we consider the following: P82a = P81a = P81b = P82b = 25-7-1815 ? Or should we consider that we only know P82a and P82b (and don't know anything about a narrower duration, thus P81) and could only declare the following:

P82a = P82b = 25-7-1815
OR
P82a = 25-7-1815 at 0:00
P82b = 25-7-1815 at 23:59

Another example: An author is know to have been elected to a club during February and March 1754 and to have left the club in 1761. Should we declare a E85 Joining with a E52 Time Span characterized by:

P82a = 01-02-1754
P82b = 31-12-1754

And a E86 Leaving with a E52 Time Span characterized by:

P82a = 01-01-1761
P82b = 31-12-1761

Last example: If we are talking about a war which started between February and March 1756 and finished in 1773, should we declare an E7 Activity with a E52 Time Span characterized by:

P82a = 01-02-1756
P81a = 31-04-1756
P81b = 31-12-1773
P82b = 31-12-1773

Thanks for your help,

Martin Scholz

unread,
Mar 17, 2016, 8:12:01 AM3/17/16
to erlangen-crm
Hi,

2016-03-16 11:49 GMT+01:00 Jean-Baptiste Pressac <jb.pr...@gmail.com>:
>
> If I understood well, P82 and P81 are durations, not dates. P82 is for the
> longuest known duration and P81 for the shortest known duration. Of course,
> it's impossible to determine the exact time at wich an historic event
> occured. Durations I guess are generaly reflecting a common understanding,
> not precise time-laps. Thus, while we could determine the exact time to the
> split second at which a space shuttle was lauched, it should be more
> difficult to determine with the same precision the end of the space mission
> (the exact second when the fist part of the landing shuttle touches the
> ground ?).
>


P81/P82 define intervals on the timeline for max/min extent of the
time span. So you always have a starting and end point for each
property, dependent on the chosen granularity.

The CRM does not expect all values of P81/82(a/b) to be of the same granularity.
That said, if you want to use xsd datatypes, you could choose the one
that is appropriate according to the record.



> So, I understood that any "date" is considered as a duration in the CRM.
> Even a birth occurring on 25Th of July 1815 should be considered as an event
> occurring between for instance 25-7-1815 at 0:00 and 25-7-1815 at 24:59. But
> in that case, what could be the values of P81a, P81b, P82a and P82b ? If we
> don't take the hours and minutes into account, should we consider the
> following: P82a = P81a = P81b = P82b = 25-7-1815 ? Or should we consider

If you set P82a = P82b = P81a = P82b that means that you exactly know the
boundaries of the time span! (max extent= min extent) ... and that the duration
is equal to the unit of your granularity.



> that we only know P82a and P82b (and don't know anything about a narrower
> duration, thus P81) and could only declare the following:
>
> P82a = P82b = 25-7-1815
> OR
> P82a = 25-7-1815 at 0:00
> P82b = 25-7-1815 at 23:59

Yes, depending on your granularity case 1 or 2. From my experience i
would also argue that
for a lot of documentation you have only information for P82, but
nothing for P81.

With the rest of the examples I agree, except in the last you probaly
wanted to write
> P81a = 31-03-1756
> P81b = 01-01-1773


Martin Scholz

> --
> You received this message because you are subscribed to the Google Groups
> "Erlangen CRM" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to erlangen-crm...@googlegroups.com.
> To post to this group, send email to erlang...@googlegroups.com.
> Visit this group at https://groups.google.com/group/erlangen-crm.
> For more options, visit https://groups.google.com/d/optout.
Message has been deleted

Jean-Baptiste Pressac

unread,
Mar 17, 2016, 11:51:24 AM3/17/16
to Erlangen CRM
Thank you for you answers. You are right, I did a mistake for my last example.

However, I am a bit surprised that I could not find P82a, P82b, P81a and P81b in the last version of Erlangen CRM. Do you know why ?

To complete the exemples, I guess that if we could say the following about the example of an author know to have been elected to a club during February and March 1754 and to have left the club in 1761:


a E85 Joining with a E52 Time Span characterized by:
P82a = 01-02-1754
P82b = 31-12-1754

And a E86 Leaving with a E52 Time Span characterized by:
P82a = 01-01-1761
P82b = 31-12-1761

We could also say about his membership in the club is characterised by this third E52 Time Span:
P82a = 01-02-1754
P81a = 31-12-1754
P81b = 01-01-1761
P82b = 31-12-1761

Vladimir Alexiev

unread,
Mar 17, 2016, 6:57:35 PM3/17/16
to erlang...@googlegroups.com
> P82a = 01-02-1754
> P82b = 31-12-1754

I would recommend this:
- do NOT add fake precision (i.e. use just 1754 in the above case)
- use proper xsd:date format (e.g. 1754-12-31)
- add proper literal types (xsd:date or or xsd:gYearMonth or xsd:gYear)
- use P82a/b only when there are 2 different dates. Else use P82 alone.
(strange but true: P82a/b are sub-properties of P82, so you’d get 2 different P82 values if there are 2 dates)

> We could also say about his membership in the club is characterised by this third E52 Time Span:

Yes. Unfortunately there’s no way to relate the Joining/Leaving to his Membership.

Martin Scholz

unread,
Mar 18, 2016, 3:54:13 AM3/18/16
to erlangen-crm
As the pdf about handling time spans is not part of the cidoc crm
directly (it's an extension),
we also do not have it in the erlangen crm.

The membership is a problem. If I need such a construct, I usually use
a (newly introduced subclass of) E4 period to "encapsulate" the
joining and leaving events via starts with/ends with.
> --
> You received this message because you are subscribed to the Google Groups "Erlangen CRM" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to erlangen-crm...@googlegroups.com.
> To post to this group, send an email to erlang...@googlegroups.com.

Vladimir Alexiev

unread,
Mar 18, 2016, 7:06:50 AM3/18/16
to erlang...@googlegroups.com
> As the pdf about handling time spans is not part of the cidoc crm directly (it's an
> extension), we also do not have it in the erlangen crm.

You should, else there's no good way to state begin_of_the_begin & end_of_the_end.
Emitting two P82 values is imho quite confusing.

> > no way to relate the Joining/Leaving to his Membership.
> I usually use a (newly
> introduced subclass of) E4 period to "encapsulate" the joining and leaving events
> via starts with/ends with.

However starts/ends are pure Allen relations with no implication of causality.

Jean-Baptiste Pressac

unread,
Mar 21, 2016, 5:40:18 AM3/21/16
to Erlangen CRM
You are right, Vladimir, I should not use french-style dates and use XML datatypes. However, why do you suggest that, when there is only one "date" (which could be I suppose, a year, a month, a day) to use only P82 and not to use P82 in combination with P82a and P82b as you used P82a and P82b for instance the year 1823 in the British Museum data repository ? What is more, reading you examples in the discussion about "Historical time ontologies and parsing in LOD" I thougth that the use of P82a and P82b was the only way to use a common XML datatype (thus xsd:dateTime) to be able to compare any time span and to know for instance if a man born the 25th july1815 could have met another man who joined a club during February and March 1754 and left it in 1761.

Why using P82a and P82b for time span whith one "date" adds "fake precision" as you said ? Saying that an event occurs during the year 1754 is itself quite imprecise.

By the way, I made some corrections:

M. Smith's date of birth (25th july1815) :

P82 = "1815-07-25"^^xsd:Date
AND
P82a = "1815-07-25T00:00:00"^^xsd:dateTime
P82b = "1815-07-25T23:59:59"^^xsd:dateTime

Another example: An author is know to have been elected to a club during February and March 1754 and to have left the club in 1761. 

We could declare a E85 Joining with a E52 Time Span characterized by:

P82 = no possible date value as there are no XML datatype for interval of dates. We could at least use the string "During 1rst february and 31th march 1754"^^xsd:string which won't be useful to know for instance if M. Smith was born during the period when the author joined the club.
P82a = "1754-02-01T00:00:00"^^xsd:dateTime
P82b = "1754-03-31T23:59:59"^^xsd:dateTime (I previously made a mistake for this value)


And a E86 Leaving with a E52 Time Span characterized by:

P82 = "1761"^^xsd:gYear
AND 
P82a = "1761-01-01T00:00:00"^^xsd:dateTime
P82b = "1761-12-31T23:59:59"^^xsd:dateTime

The time-span during the author was member of the club:

P82 = "During 1rst february1754 and 31th december 1761"
P81 = "During 31th March 1754 and 1rst january 1761"
P82a = "1754-02-01T00:00:00"^^xsd:dateTime
P81a = "1754-03-31T23:59:59"^^xsd:dateTime (I am not sure about P81a and P81b)
P81b = "1761-01-01T00:00:00"^^xsd:dateTime
P82b = "1761-12-31T23:59:59"^^xsd:dateTime

A war which started between February and March 1756 and finished in 1773, we could declare an E7 Activity with a E52 Time Span characterized by:

P82 = no possible date value as there are no XML datatype for interval of dates. We could at least use the string "During 1rst february1756 and 31th december 1773"^^xsd:string
P81 = no possible date value as there are no XML datatype for interval of dates. We could at least use the string "During 31th march 1756 and 1rst january 1773"^^xsd:string
P82a = "1756-02-01T00:00:00"^^xsd:dateTime
P81a = "1756-03-31T23:59:59"^^xsd:dateTime
P81b = "1773-01-01T00:00:00"^^xsd:dateTime (I made a correction here)
P82b = "1773-12-31T23:59:59"^^xsd:dateTime

Vladimir Alexiev

unread,
Mar 21, 2016, 6:30:08 AM3/21/16
to erlang...@googlegroups.com
> Why using P82a and P82b for time span whith one "date" adds "fake precision" as you said ?

Say you’re representing Production, and you have info when the production of some painting started and finished.
With “fake precision” your consumers can’t distinguish painting production that actually started on 1 Jan from a date that was fake-completed to 1 Jan

> Saying that an event occurs during the year 1754 is itself quite imprecise.

But it’s true to the precision with which the info was available.

THE REST of the discussion depends on whether you agree that P82a/b should not add fake precision to dates, or not.

> to be able to compare any time span and to know for instance if a man born the 25th july1815 could have met another man who joined a club during February and March 1754 and left it in 1761.

Whether you can compare xsd:date to xsd:gYear depends on the software you use.
- These literals are constructed in such a way that for AD dates, simple string (lexicographic) comparison works
- the SPARQL standard only says that xsd:dateTime are comparable
- Ontotext GraphDB can compare xsd:dateTime and xsd:date and has special “literal” indexes that make this fast. So gYear, gYearMonth woudl not be recommended for speed reasons

Everything else I wrote concerns a truthful representation of the historic data, not comparability in specific software frameworks (but of course that’s also important)

> why do you suggest that, when there is only one "date" (which could be I suppose, a year, a month, a day) to use only P82 and not to use P82 in combination with P82a and P82b

Because you don’t have more to say than one date.

> as you used P82a and P82b for instance http://collection.britishmuseum.org/id/object/YCA11/acquisition/date in the British Museum data repository ?

Thinking has evolved in the last 4 years ;-)

> thougth that the use of P82a and P82b was the only way to use a common XML datatype (thus xsd:dateTime)

Nobody ever said that P82 could not include a valid xsd date-type.

> P82 = "1815-07-25"^^xsd:Date
> AND
> P82a = "1815-07-25T00:00:00"^^xsd:dateTime
> P82b = "1815-07-25T23:59:59"^^xsd:dateTime

Ok, so you have 2 fields comparable according to the SPARQL standard (xsd:dateTime) and one reflecting historic precision (xsd:Date: should be lowercase!)
Unfortunately P82a&b are sub-props of P82, so you’ll have 3 values for P82, and how can your consumer know which is historically true and which are fake-completed?

> An author is know to have been elected to a club during February and March 1754
> P82a = "1754-02-01T00:00:00"^^xsd:dateTime
> P82b = "1754-03-31T23:59:59"^^xsd:dateTime
> P82 = no possible date value as there are no XML datatype for interval of dates.

As I said above, P82a&b will be copied into P82 since they are sub-properties.

> string "During 1rst february and 31th march 1754"^^xsd:string

Put that in P3_has_note of the Time-Span.

Jean-Baptiste Pressac

unread,
Mar 21, 2016, 8:03:00 AM3/21/16
to Erlangen CRM
Hello,
However, P82a/b and P81a/b are implemented in the official RDFS implementation of the CRM since January 27, 2015: http://cidoc-crm.org/rdfs/cidoc_crm_v6.0-draft-2015January.rdfs. Would it be possible to implement them in Erlangen ?
Thanks,

Christian-Emil Smith Ore

unread,
Mar 21, 2016, 1:07:18 PM3/21/16
to erlang...@googlegroups.com
Hi
Jon Holmen and I wrote a paper in 2009 including an exemplification of P81 &P82
http://proceedings.caaconference.org/paper/17_holmen_ore_caa2009/

Best,
Christian-Emil

Vladimir Alexiev

unread,
Mar 23, 2016, 6:32:22 AM3/23/16
to erlang...@googlegroups.com

>> reading you examples in the discussion about "Historical time ontologies and parsing in LOD" I thougth

>> that the use of P82a and P82b was the only way to use a common XML datatype (thus xsd:dateTime) to be able to compare any time span

> Nobody ever said that P82 could not include a valid xsd date-type.

 

I reread the above discussion, and it shows xsd:date in P82 and “fake-completed” xsd:dateTime in P82a/b.

It points out that:

> SPARQL mandates only comparison of xsd:dateTime and has no automatic casting. 
> OWLIM (now GraphDB) supports comparison of xsd:date and xsd:dateTime (and no automatic casting). 

 

It also says:

>  it's not a good idea to "overwrite" original/historic dates with "completed datetimes": it's better to do the completion in separate "service/auxuliary" fields. 

 

The problem is that there’s no standardization of such "service/auxuliary" fields.

So perhaps all things considered, it is best at present to use P82a/b for “fake-completed” xsd:dateTime or xsd:date (to facilitate comparability).

Reply all
Reply to author
Forward
0 new messages