[Crm-sig] issue-288-AV_MD.doc
Richard Light
richard at light.demon.co.uk
Thu Jan 11 18:06:36 EET 2018
On 11/01/2018 14:39, Martin Doerr wrote:
> Dear Richard,
>
> Your comments well-taken, but I regard it as pointless to use less
> precise data types. This is, to my opinion, exclusively an issue of
> automatic conversion
> in the data entry forms. We at FORTH have conversion libraries. Data
> entry utility ("ca 730 BC") must not be confused with internal data
> representation for interoperability (xsd:....), and not with
> ontological-logical modelling (time as isomorphic with real numbers).
>
> I do not know how RDF-compatible databases do arithmetic with mix of
> time data types. Any insight? We must avoid meaningless equality
> between imprecise dates. I assume there is no default interval
> arithmetic in place that could handle 28-6-1951 to be possibly before
> something that happened in "1951" .
Martin,
So we agree that the ultimate storage format should be precise, in the
manner described by the draft document. I take your point about the
distinction between a data entry interface and the ultimate storage
format in the RDF. However, I think a description of our RDF solution
for P81/P82 which is expressed solely in these terms will convince most
practitioners that our RDF implementation is too complex to be used with
'real' museum data.
I think it would be a good idea to include some examples of dates, in a
form which might be found in collections catalogues, and show (a) how
they should be expressed in abstract terms (P81/P82) and then (b) how
they should be rendered as RDF (P81a/P81b/P82a/P82b). We can also point
out that these conversions can be carried out programmatically.
Best wishes,
Richard
>
> I copy to Christian-Emil, because he should give us his theory of
> negative P81 intervals.
>
> Best,
>
> Martin
>
>
>
> On 1/11/2018 3:50 PM, Richard Light wrote:
>>
>> Hi,
>>
>> Not all of my corrections were picked up. Updated version (with some
>> other minor changes) attached. I tried desperately to switch on
>> 'track changes' (saving it as .docx in an attempt to do so), but I
>> have no idea whether Word has actually done this. I did try!
>>
>> I wonder if it is helpful to include the paragraph about overlapping
>> 'end of begin' and 'begin of end': the concept is already hard enough
>> to understand without throwing this into the mix.
>>
>> As regards the substance of the proposal, I would observe that there
>> are other W3C date types, for example gDate and gYear [1]. I agree
>> with the goal of expressing dates in a way which is amenable to
>> machine processing, but the suggested approach appears to require
>> users to record to a spurious precision, which will never be present
>> in the source data.
>>
> No, see above.
>>
>> (If we're following W3C guidelines in full, a DateTime value should
>> have an associated time zone, declared explicitly or implicitly
>> assumed to be UTC. We don't actually give an example showing this.)
>>
> Yes, of course.
>>
>> I suggest, instead, that we say that when a W3C date, of whatever
>> sort, is given as the value of P81a or P82a, then it should be
>> interpreted as representing the /beginning /of the time period
>> expressed by that date. When such a date is given as the value of
>> P81b or P82b, it should be interpreted as representing the /end /of
>> the time period expressed by that date. (Re-reading the text, I do
>> wonder if this is what was actually meant. It depends what you mean
>> by "the implementation". If so, I certainly misunderstood it the
>> first time around.)
>>
> Yes, that's what I meant, but at data entry time. We have an
> interpreter for the AAT guidelines how to record time, which has all
> those "ca" etc. There is also the "display date P79, P80, to capture
> the scholarly expression.
>>
>> I think the guidance should contain examples using both gYear and
>> gDate, showing how to record e.g. "date of birth recorded as
>> 4.12.1854" and "building not started before 1736; definitely
>> happening 1745-1750; finished by 1754 when it was opened" as RDF.
>>
>> Best wishes,
>>
>> Richard
>>
>> [1] https://www.w3.org/TR/xmlschema11-2/#gYear
>>
> Best,
>
> Martin
>>
>>
>> On 10/01/2018 19:38, Martin Doerr wrote:
>>>
>>> Here my latest edits, thanks to Richard's comments:-)
>>>
>>>
>>> --
>>> --------------------------------------------------------------
>>> Dr. Martin Doerr | Vox:+30(2810)391625 |
>>> Research Director | 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) |
>>> |
>>> N.Plastira 100, Vassilika Vouton, |
>>> GR70013 Heraklion,Crete,Greece |
>>> |
>>> Web-site: http://www.ics.forth.gr/isl |
>>> --------------------------------------------------------------
>>
>> --
>> *Richard Light*
>
>
> --
> --------------------------------------------------------------
> Dr. Martin Doerr | Vox:+30(2810)391625 |
> Research Director | 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) |
> |
> N.Plastira 100, Vassilika Vouton, |
> GR70013 Heraklion,Crete,Greece |
> |
> Web-site: http://www.ics.forth.gr/isl |
> --------------------------------------------------------------
--
*Richard Light*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180111/1b561773/attachment.html>
More information about the Crm-sig
mailing list