[crm-sig] Issue:6. How to model databases, issue 69. Spatiotemporal overlaps of periods

martin martin at ics.forth.gr
Mon Jan 28 16:12:13 EET 2002

Issue 6: How to model databases.

Following the proposal from Paris to treat databases as Information Objects, the question is, if it has any characteristic
properties that would justify an individual entity in the CRM. The only properties I can think of is:

"is composed of"

I can hardly think of a database which does not document. Databases as art objects are still to be invented, or may not
be regarded as databases.

Therefore I propose to include databases in the scope note of documents.


Issue 69: Spatiotemporal overlaps of periods.

In Paris I was ask to explain my position with respect to the spatiotemporal overlaps of periods. I propose to
use except for the part-whole relation and the inclusion only one more purely spatiotemporal relationship:

Here my view:

If we declare a property in the CRM, it should be clearly defined and clearly needed for the purpose of the CRM
both in functionality and in frequency of use.

>From a mathematical point of view, all topological relationships can be derived from the inclusion. This
may in practice be quite clumsy: E.g. in order to define an overlap we have to include the common part by
both entities. So we have to define somehow artificially the overlapping part etc. So one argument is to introduce
additional relationships for convenience.

Now, Periods extend over a 4-dimensional space. Such a space has no complete order, and arbitrary directions in
time-space like the flight of a plane have few cultural relevance - i.e. we shall hardly find a documentation with
enough data to decribe it precisely. Equally unlikely is the chance, to compare such data with others for reasoning,
e.g. when the plane crashed into the building. More likely, we shall find documented relationships restricting
overall time or place or both. So another argument is the complexity to handle relationships in multiple dimensions
and the probability tofind data for them.

Finally, the purpose of the CRM is to facilitate resource discovery by precise descriptions. More specialized relationships
can be replaced by simpler ones, which preserve recall. E.g. instead of seeking the plane that crossed Halifax at
16:00, I can search for planes on the route over Halifax within +/- 8 hours. This will return more planes than I needed,
but it will include the candidates.

Temporal bounds are typically rich and with good precision in cultural documentation. The fact, that time is
one-dimensional makes comparison easy. Therefore we have already decided on the relatively rich temporal
relationships by Allen, which can be regarded as a standard in Knowledge Representation and are well studied
and well-understood:

before (after) :                               E2 Temporal Entity
     meets in time (met-by in time):    E2 Temporal Entity
     overlaps in time (overlapped-by in time):   E2 Temporal Entity
     during (includes):                          E2 Temporal Entity
     starts (started-by):                        E2 Temporal Entity
     finishes (finished-by):                   E2 Temporal Entity
     equal in time:                                E2 Temporal Entity

All those are also available for Periods to describe the extent in time via inheritance.

Spatial relationships already deal with 2 or 3 dimensions. We have decided in Paris to use:
E53 Place - "borders with: E53 Place", "overlaps with: E53 Place".

Those have a high frequency in our data. Countries etc. have borders, modern districts may overlap
with ancient ones etc. Reasoning and retrieval based on these is straightforward. One could introduce direction,
like "north of" , distances etc. Reasoning and retrieval of such data exceeds the capabilities of usual applications.
Of course GIS can deal with that. On the other side, if I look for some places being "north of" a known one,
I can determine the area by hand and post a query on that base. Therefore we have decided in Paris, that
the above spatial relationships together with inclusion are sufficient and appropriate for the CRM.

These spatial relationships are available to describe related periods. Hence, Periods can be restricted in
time and in space by the above relationships. What else do we need?

As Periods can spread out over time and space in a "non-rectangular shape", i.e. not constant for a certain
time-span at some spatial borders, even two Periods in the same time and space "box" need not overlap.
Let us think for instance of some fashion movement coming from the US to Europe, and before it ends
in Europe, another movement in the US has already taken over. A purely spatiotemporal overlap, which cannot be
decomposed into spatial and temporal overlaps, is relatively rare, but difficult to be described otherwise.
It is also culturally relevant, because we can fairly assume mutual influences, or wonder why these periods
behave independently.

Therefore I have proposed to include the pure spatiotemporal overlap as relationship for the CRM.
All other purely spatiotemporal relationships I regard as too complex for a standard.

I could only imagine one more relevant relationship between Periods: "follows". Imagine a situation as with the
fashion movement above. There is no overall temporal sequence, but at any individual place, the second period
"follows (is followed by)" the first. This would be a complement to the spatial "borders with", and a refinement
of the temporal "meets", relative to the various points in the respective area a period is active.



 Dr. Martin Doerr              |  Vox:+30(81)391625          |
 Principle Researcher          |  Fax:+30(81)391609          |
                               |  Email: martin at ics.forth.gr |
               Information Systems Laboratory                |
                Institute of Computer Science                |
   Foundation for Research and Technology - Hellas (FORTH)   |
 Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
         Web-site: http://www.ics.forth.gr/proj/isst         |

More information about the Crm-sig mailing list