[Crm-sig] ISSUE 240: Start/End vs Period of Existence

Dominic Oldman DOLDMAN at britishmuseum.org
Mon Apr 21 11:39:41 EEST 2014


From a slightly more high level perspective I have the following observation triggered by something that Martin put in his response but based on a number of emails to the list over the last couple of years. Given the increase in the use of and interest in the CRM I hope that it is useful.

Cultural Heritage data is multi-layered and highly variable. Curatorial, multiple disciplinary perspectives and research requirements contribute to these characteristics. The moment that we start to talk about, “there is no standard way” or it would be “more economical”, alarm bells are raised. While efficiency can be beneficial without being detrimental the desire of technologists to standardise cultural heritage data is exactly the reason why we need the CRM.

The CRM has been developed precisely to support the fact that you cannot make sweeping assumptions across it and that representations must be based on expert domain analysis rather than what might be easier for a programmer.  The historic quest for standardisation by technologists is a significant factor in explaining why many cross-organisational cultural heritage systems have been unsuccessful (finally recognised by people who worked on these systems in the 1990s and resulting in the clear need for the CRM).

Humanities scholars are often disillusioned by computer information systems because of the tendency to provide a one-dimensional approach prioritising optimisation, performance and ultimately superficially over representing knowledge as validly as possible. It is a mistake to think that cultural heritage experts want these things in preference to this integrity.  In any event it is easy to implement the CRM without compromise (through collaboration) and produce highly usable and accessible systems. There is no need to artificially standardise the CRM in a way that compromises its raison d'etre.

Unless software starts to reflect the methods and understanding that underpin the work of cultural heritage researchers and academics (this means that computer system experts need to work with and collaborate with humanities experts) then it is unlikely that computer systems will contribute significantly or realise the promise that those involved in humanities computing thought that they might many decades ago.

Dominic
Dominic Oldman
Deputy Head of Information Systems, IS Development Manager,
ResearchSpace Principal Investigator,
British Museum
Sent from Blackberry: 07980865309

From: martin [mailto:martin at ics.forth.gr]
Sent: Saturday, April 19, 2014 07:38 PM
To: crm-sig at ics.forth.gr <crm-sig at ics.forth.gr>
Subject: Re: [Crm-sig] ISSUE 240: Start/End vs Period of Existence

Hi Vladimir,

Good initiative, but a lot of these things have been discussed in length in
CRM-SIG, and recently we have entered a discussion about start events of periods.
I'll point you to respective literature, please have a look at that.

Please do not propose too many things at a time, it makes it difficult to manage
the issue.

In continuation of Stephen: Yes, it is intentional that states that can only be
acquired by explicit events, such as ownership, membership etc., are described
by these events. This is to ensure monotonicity under increase of incomplete,
but consistent knowledge. True life-long observation is extremely rare, therefore
most such states are concluded from events. If this is the case, these should be
documented, and not the states. The states should be deductions, and any user
of the CRM is free to introduce such deductions.

"Modeling such Periods of Existence is significantly more economical than modeling with Start/End events. "

This is no argument. Firstly, the size of all metadata together are a negligible fraction of image
data we keep. Secondly, these events are the hooks for other, distinct, historically relevant
information. Birth and death have quite different contexts and actors involved.

Not all periods can have start or end events. Simply, because the event itself has
a duration as a fact of physics, and this creates and infinite recursion. To define properties
is easy. What we need is an understanding of the semantics of "starting something".
Is there an concept of cause or occasion? How does a start event behave in space-time?

See in particular:

  1.  Doerr, M., Kritsotaki, A., & Stead, S. (2005). Thesauri of historical periods - A proposal for standardization. In Proceedings CIDOC '05 Conference, Zagreb, Croatia, 24-27 May.
  2.  Doerr, M., Kritsotaki, A., & Stead, S. (2004). Which Period is it? A Methodology to Create Thesauri of Historical Periods. Computer Applications and Quantitative Methods in Archaeology Conference, CAA2004, Prato, Italy, 13-17 April.

"momentary events" are a fiction of computer science. A basic requirement for the CRM is that it is
scale-invariant. There is no smallest granularity for events we could easily point to.

You write:
"HOWEVER, there is no standard way to state the "Period of use/existence/activity of something", such as: - period of use of an Identifier (Appellation, Title), Type - life of a Person - floruit of a Person"

Use of an identifier and the floruit of a person is explicitly modelled in FRBRoo v2.0.

The problem with states, such as "period of use" is the open world semantics:
What is actually observed knowledge, and what is inference? This distinction
is the "soul" of the CRM. See the CRM Sci extension just publioshed on the CRM site
for a definition of states. Expecting your comments.

See also Doerr, M., & Hiebel, G.H (2013). CRMgeo: Linking the CIDOC CRM to GeoSPARQL through a Spatiotemporal Refinement. 2013.TR435_CRMgeo_CIDOC_CRM_GeoSPARQL.pdf<http://www.ics.forth.gr/tech-reports/2013/2013.TR435_CRMgeo_CIDOC_CRM_GeoSPARQL.pdf>.

Finally, events and temporal knowledge is fuzzy. Allen relationships have only temporal
meaning, they are accidental.

See also:
Doerr, M., Plexousakis, D., Kopaka, K., & Bekiari, Ch. (2004). Supporting Chronological Reasoning in Archaeology. In Computer Applications and Quantitative Methods in Archaeology Conference, CAA2004, (pp. 13-17).

For dealing with fuzzy boundaries.

Indeed, life of a person is one of the candidates for a period with start/end events, but,
is it a "Period" or just the spacetime volume of the person?

best,

martin



On 19/4/2014 4:39 μμ, Stephen Stead wrote:

Vladimir
I am not trying to answer all your points but I have a couple of comments
that may address several of them.
In general we have taken the design approach of not modelling condition
states as they tend to lead to monotonicity problems when combining
different data streams. As far as I can remember a parallel effort by a
different research group did try that approach and ran into so many problems
with their model that the development effort was abandoned. However, not
before we had harmonised the constructs they had with the CRM.
Our contention is that it is always better to calculate at query time what
the current state of knowledge indicates is the period that a state existed.

We also consider it axiomatic that no event is "momentary": all temporal
events have duration.
HTH
Rgds
SdS


Stephen Stead
Tel +44 20 8668 3075
Mob +44 7802 755 013
E-mail steads at paveprime.com<mailto:steads at paveprime.com>
LinkedIn Profile http://uk.linkedin.com/in/steads


-----Original Message-----
From: Crm-sig [mailto:crm-sig-bounces at ics.forth.gr] On Behalf Of Vladimir
Alexiev
Sent: 19 April 2014 12:00
To: 'crm-sig'
Subject: [Crm-sig] ISSUE 240: Start/End vs Period of Existence

Hi!

(An issue that arose at public-esw-thes at w3.org<mailto:public-esw-thes at w3.org> under subject Re: TGN place
types (broader/narrower spanning ConceptSchemes) and was discussed to some
extent between me and Richard Light)

There are many "dual" Events in CRM that indicate the Start/End of
something:
- Beginning/End of Existence
- Birth/Death of a person
- Identifier Assignment with props assigned/deassigned
- Acquisition with props transferred from/to
- Transfer of Custody with props from/to
- Production/Destruction (not completely dual)
- Part Addition/Removal
- Formation/Dissolution of a group
- agent Joining/Leaving a group

There are also events that indicate Start, without a corresponding End
event:
- Creation (End is not appropriate, since conceptual things are forever)
- Type Assignment (IMHO should also have "type deassigned", just like
Identifier Assignment)

HOWEVER, there is no standard way to state the "Period of
use/existence/activity of something", such as:
- period of use of an Identifier (Appellation, Title), Type
- life of a Person
- floruit of a Person
- period of group membership or profession of a Person (e.g. reign) One
would have to model them as Event/Activity in which the concerned entity
participated, with some P2_has_type.

We also need to relate the start/end events to the period of existence.
P116_starts and P115_finishes almost fit the bill, though they bind only one
of the endpoints.
E.g. P115: "allows the ending point for a E2 Temporal Entity to be situated
by reference to the ending point of another temporal entity of longer
duration".
P115 makes no relation between the starting points. But Death is *the* end
of Life, so *both* points of Death must be strongly related to the ending
point of Life.
- We could introduce sub-properties:
  P216 really starts (really started by): "an E2 Temporal Entity (e.g.
Birth) is considered to be "momentary", and is the start of a longer E2
Temporal Entity (e.g. Life)"
  P215 really finishes (really finished by): "an E2 Temporal Entity (e.g.
Death) is considered to be "momentary", and is the finish (end) of a longer
E2 Temporal Entity (e.g. Life)"
- These should be subproperties not only of starts/finishes, but also of
forms_part_of :
  P216_really_starts rdfs:subPropertyOf P116_starts, P9i_forms_part_of.
  P215_really_finishes rdfs:subPropertyOf P115_finishes,
crm:P9i_forms_part_of.
(This is optional, we could just use P116 and P115)

Finally, we need some rules to relate the 4 time-points (P82a, P81a, P81b,
P82b) of the Start/End events to those of the Existence period.
I'm not sure what the rules should be... One approach could be that:
- Start/End are considered "momentary" events, thus have only 2 points
(P81a=P82a, P82b=P81b)
- these points correlate to Existence as follows: Start.P82a=Existence.P82a,
Start.P82b=Existence.P81a, End.P82a=Existence.P81b, End.P82b=Existence.P82b.
Maybe this is a bit naïve, since:
- "momentary" is a relative term. Birth could be described as a minute
event, usually is described as an  the "expected" inequalities
P82a<=P81a<=P81b<=P82b do not always hold, see
  Deducing event chronology in a cultural heritage documentation system
(Holmen & Ore, CAA 2009)

Modeling such Periods of Existence is significantly more economical than
modeling with Start/End events.
So I think this is a new important shortcut pattern: one event (e.g. Life)
being the shortcut expression of two events (Birth/Death).
I expect the classical objection will be raised, that Life is not used often
in cataloging practice.
But if there's enough interest to have explicit classes for Birth/Death, how
can there be not enough interest to have specific class for Life?

In the attached Turtle file I've defined a couple of extension classes (Life
and Membership) and given some examples.
Note that Joining/Leaving are longcuts of Membership, which itself is a
longcut of P107_has_current_or_former_member.
So it's interesting that we've discovered an expression at intermediate
level of detail between super-detailed (Joining/Leaving) and undetailed
(P107)

I give an example of a king whose reign finishes with his life (descension
coincides with Death).
It would be interesting to try to model Picasso's creative periods with this
machinery, e.g. see http://en.wikipedia.org/wiki/Picasso
http://en.wikipedia.org/wiki/Picasso%27s_Blue_Period

Cheers! Vladimir


_______________________________________________
Crm-sig mailing list
Crm-sig at ics.forth.gr<mailto:Crm-sig at ics.forth.gr>
http://lists.ics.forth.gr/mailman/listinfo/crm-sig





--

--------------------------------------------------------------
 Dr. Martin Doerr              |  Vox:+30(2810)391625        |
 Research Director             |  Fax:+30(2810)391638        |
                               |  Email: martin at ics.forth.gr<mailto:martin at ics.forth.gr> |
                                                             |
               Center for Cultural Informatics               |
               Information Systems Laboratory                |
                Institute of Computer Science                |
   Foundation for Research and Technology - Hellas (FORTH)   |
                                                             |
               N.Plastira 100, Vassilika Vouton,             |
                GR70013 Heraklion,Crete,Greece               |
                                                             |
             Web-site: http://www.ics.forth.gr/isl           |
--------------------------------------------------------------


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20140421/855ad290/attachment-0001.html>


More information about the Crm-sig mailing list