[Crm-sig] Extended CRM Graph of E52 Time-Span
martin at ics.forth.gr
Sat Aug 1 15:09:24 EEST 2009
Thank you for the extended explanations.
Bernhard Schiemann wrote:
> Dear all,
> the reason why we introduced P79a and P80a was that we cannot see from
> the latest release of the CRM text how the following problem can be
> (For illustration see the attached edited version of Cristian-Emil's
> There is an E52 Time-Span named A which has an "interval for start
> point(!)" called A_s and an "interval for end point" called A_e.
> Hence, A is a fuzzy time-span with a vague start and and a vague end.
> The starting interval A_s has borders A_s_s (start) and A_s_e (end)
> --- and the same holds by analogy for A_e. The CRM document relates
> A_s_s and A_e_e by P82 at some time within and A_s_e and A_e_s by P81
> ongoing throughout.
> NOW: If we want to express the relation between A_s, which is an E52
> Time-Span, and its start A_s_s, what ist the appropriate property to be
> used? This depends on what A_s_s is:
> - If its also interpreted as an E52 Time-Span, there is no reason not
> to repeat this step which will result in an infinite recursion.
> Furthermore, it does not really make sense in the framework we are
> dealing with: We want to talk about time intervals with vague
> (fuzzy) borders; so what would it mean if we make the borders of the
> start and end intervals fuzzy in turn, i.e. making vague the start
> of the start of the start... ?
> - Another interpretation would be to regard A_s_s as an E61
> Time-Primitive which is given precisely (with an a priori assumed
> granularity of time determination depending on the respective
> application). A footnote aside: We may shift A_s_s etc. forth and
> back on the time line until we have sufficient certainty with
> respect to P82 or P81, respectively.
> If we decide for the second interpretation, our suggestion for the
> properties to relate A_s and A_s_s was P79a and for A_s and A_s_e it
> was P80a. Otherwise, the only eligible CRM relations we can see to
> relate E52's to E61's are (the already employed) P81 and P82.
To my best knowledge, the only consistent way to deal numerically with
non-discrete REAL numbers, such as time, is interval arithmetic.
The fact, that OWL does not foresee the appropriate time primitive to deal
with non-discrete time should not lead to decisions to extend the CRM itself with
work-around for that. I completely agree with your interpretation as
given in your attached drawing. Since this is an implementation issue
(there may be other environments where we may need to split date and time-of-day
or whatever), the only question that arises in my opinion is which is the
most efficient implementation, and if there is a transformation algorithm
to any other compliant one.
> In contrast to Martin's suggestion (July 2) A_s_s and A_s_e are
> preserved as E61 Time-Primitives (which still have an interval
> property in terms of the choosen granularity; see above).
Therefore I do not see a value in saving A_s_s etc as "E61" , and instead
introducing another indirection, where most current triple stores are built
on RDBMS, suffering from poor join performance.
So, the difference between my proposal and yours is, that you introduce
another join solely to name the endpoint again E61?
If I understand you correctly, otherwise what you suggest now in your drawing
and what I proposed is completely isomorphic?
Note further, that xsd dateTime does not have the appropriate rounding error
treatment built-in to "shift A_s_S etc." apropriately. This is the reason why
a mathematically exact implementation of interval arithmetic must make the
interval itself a primitive.
It was not the intention of declaring "Primitive Values" in the CRM, that
they are implemented as user-defined classes and further indirected with links to
local primitive values.
(I would rather agree with throwing the whole Time-Span out in a real implementation,
if we are sure there will not be multiple Time-spans for events.)
> So, of course, P79a and P80a where not at all conceived as a kind of
> replacement for A_s_s and A_s_e. But if we want to "calculate" with
> time intervals, as a scope note in the CRM document, referring to
> Allens constraint system, says, it must be possible to determine
> values for A_s_s and A_s_e of some data type, e.g. xsd:dateTime.
> Probably there are alternative solutions --- therefore we put the
> issue on the list to stimulate a constructive discussion. So far, we
> cannot see any; of course we acknowledge the detailed explanation
> referring to start and end intervals which set the frame for possible
> solutions but does not yet provide one. Maybe our P79a / P80a
> suggestion is "oversimplified", but what would then be alternative
> more complex, but appropriate solution?
> Dear Martin, it seems that you have not noticed that "clear cut" was a
> quotation (therefore the quotation marks) from Christian-Emil's
> original mail where he quotes from a paper he published recently. So
> you will have to discuss the proper use of terms with him.
> As for the remark in your mail of July 2 on the the use of abstract
> datatypes in ontologies, there is a lot of literature which says the
> opposite. In particular you may have missed the recent recommendations
> of the W3C for OWL2, the Web ONTOLOGY Language, which offers extended
> means for the definition of abstract datatypes (sometimes also called
> "concrete domains"). One of the reasons was to avoid reference to
> xsd:... datatypes which, although permitted, some people in the OWL
> group found troublesome. To provide means for the definition of
> expressive abstract datatypes within the language is quite obvious
> --- and has been an issue on the side of applied logics for more than 15
> years ---, because you need them in order to get some real inference
> tasks with real data to be done.
> On behalf of the authors from Erlangen, Best regards,
> Crm-sig mailing list
> Crm-sig at ics.forth.gr
Dr. Martin Doerr | Vox:+30(2810)391625 |
Principle Researcher | Fax:+30(2810)391638 |
| Email: martin at ics.forth.gr |
Center for Cultural Informatics |
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/isl |
More information about the Crm-sig