Historical time ontologies and parsing in LOD

[Rein van 't Veer]

Hello LODLAM,

In an effort to tie together several questions and answers regarding historical time in LOD, I chose this forum as a place as suggested by Vladimir (thanks). My question is as follows: we, from the Heritage & Location project, are to assemble a lot of enriched linked data on cultural heritage institutions throughout the Netherlands. Heritage & Location is a semantic web initiative for the Dutch cultural heritage sector, offering infrastructure, web viewers and tools, business models and crowdsourcing tools. 

In some alarming messages, there seems to be a lack of implementations that can properly parse historical time occurences in linked data in order to reason over it, but perhaps things are not as bad as they seem. I raised this question in mails, on internal boards and in conversations, and in a presentation at the Linked Data Benchmark Council - Fourth Technical User Community. 

So for example, my use case would be to query my linked data store, asking for all early-medieval cultural heritage concepts. 

The questions are then simply formulated as:

1. What ontology should I use to describe my 'fuzzy' periods and their temporal bounds?

2. How am I to annotate, say, the event of the assassination of Caesar on March 15, 44 BC in linked data? 

3. What triple stores are able to equate this event with the Roman period?

4. Can this kind of reasoning be done using OWL (or would I even want this?)

I have already received quite some very valuable input, some of which I will try to summarize. I must admit that I have not been able to follow up much of their suggestions as of yet. But I already thank the many very helpful contributions. 

• Victor de Boer has used the TIMEX vocabulary, but I do not know what kind of components he uses for querying/parsing. His suggestion is also to leave the original time description from the heritage data as is, and include enriched data in Heritage & Location to reason with.
  
• Rob Warren made an ontology for Monuments and Graves and gave a lot of helpful suggestions that cover too much to repeat here for the moment.
• Milco Wansleeben suggested W3 Time. I looked into this a bit and it seems that the ontology itself isn't intended for historical events, but for describing documents and web services (although the example used on the page is about the birth of a person).
• Joop Vanderheiden contributed an ontology based on the Archaeological Base Register to Heritage & Location (not online as of yet)
• Paul Cripps and Keith May pointed me to CIDOC-CRM, although I suspect the exact temporal descriptions in CIDOC:E50_Date are too loosely described (xsd:string) to be of use
• Linda van den Brink and others in our Vocabulary pilot group are investigating the Europeana Data Model
• Gerard Kuys is developing an event ontology for DBpedia
• I briefly discussed OWLIM support for time BC - I believe he stated that "-0044-03-15"^^xsd:date for Caesar's demise (did I get this right?) should be possible in OWLIM, but I still have to try.
• Kostis put me on the track of Strabon, a spatio-temporal RDF triple store, but I have only tested the spatial part

So to conclude: I received a lot of very helpful information for encoding temporal information, and frankly I'm a bit flustered. At some time I would have to select a solution that should both offer good spatial support (which is a bit rich to be discussed here also), good temporal support and reasoning. I would very much welcome suggestions on this part as well.

Thanks in advance,

Rein van 't Veer

Heritage & Location

[Simon Spero]

For a good overview of temporal Ontology, see Pat Hayes -  http://www.ihmc.us/users/phayes/docs/timeCatalog.pdf

That should cover some of the choices in theories that other documents are using; fortunately  you don't have to read all of it.

You should probably take a look at Ryan Shaw's Linked Open Descriptions of Events (LODE);

http://escholarship.org/uc/item/4pd6b5mh ,

which was developed from explicitly from  a cultural heritage perspective.

Description Logics are not strong enough to express all of the standard temporal axioms; however some may be covered by SPARQL- others may require stronger reasoning. 

There are also some tricky issues covering multiple events known only by fuzzy/coarse grained dates that you may want to address at some point.

For example, you might know empirically that someone doing something , and that person dying, occurred on a certain day; you might also believe analytically that one event must have occurred before the other. There are tricks to temporal reasoning of this kind.
[People can do things after being killed (like writing dying messages in blood ); after dying less so (unless you're Mark Twain (Spirit)).]

--
You received this message because you are subscribed to the Google Groups "Linked Open Data in Libraries, Archives, & Museums" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lod-lam+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Antoine Isaac]

Hi,

(I see that http://id.loc.gov/authorities/names/n82045653 strikes again ;-) )

I've read recent things about the problem, and they were pointing to the work you've already cited, so not much to add.
Except a couple of things:

- that there's a more recent pointer to the LODE vocabulary, in case it's not in the paper: http://linkedevents.org/

- there must be really data on periods in Wikidata, for example http://www.wikidata.org/wiki/Q2277

- the Pleiades project has some time periods, e.g. http://pleiades.stoa.org/vocabularies/time-periods/chalcolithic-iran
it can be downloaded at https://github.com/isawnyu/pleiades-rdf
but it doesn't seem to use a specific time-related ontology.

Antoine

On 4/8/14 9:46 PM, Simon Spero wrote:
> For a good overview of temporal Ontology, see Pat Hayes - http://www.ihmc.us/users/phayes/docs/timeCatalog.pdf
>
> That should cover some of the choices in theories that other documents are using; fortunately you don't have to read all of it.
>
> You should probably take a look at Ryan Shaw's Linked Open Descriptions of Events (LODE);
>
> http://escholarship.org/uc/item/4pd6b5mh ,
>
> which was developed from explicitly from a cultural heritage perspective.
>
> Description Logics are not strong enough to express all of the standard temporal axioms; however some may be covered by SPARQL- others may require stronger reasoning.
>
> There are also some tricky issues covering multiple events known only by fuzzy/coarse grained dates that you may want to address at some point.
>
> For example, you might know empirically that someone doing something , and that person dying, occurred on a certain day; you might also believe analytically that one event must have occurred before the other. There are tricks to temporal reasoning of this kind.
> [People can do things after being killed (like writing dying messages in blood ); after dying less so (unless you're Mark Twain (Spirit)).]
>

> On Apr 8, 2014 12:49 PM, "Rein van 't Veer" <rein.v...@den.nl <mailto:rein.v...@den.nl>> wrote:
>
> Hello LODLAM,
>

> In an effort to tie together several questions and answers regarding historical time in LOD, I chose this forum as a place as suggested by Vladimir (thanks). My question is as follows: we, from the Heritage & Location <http://www.erfgoedenlocatie.nl> project, are to assemble a lot of enriched linked data on cultural heritage institutions throughout the Netherlands. Heritage & Location is a semantic web initiative for the Dutch cultural heritage sector, offering infrastructure, web viewers and tools, business models and crowdsourcing tools.
>
> In some alarming messages <https://groups.google.com/d/msg/4store-support/TQKrHbG0o1s/qU-I7cBmCI0J>, there seems to be a lack of implementations that can properly parse historical time occurences in linked data in order to reason over it, but perhaps things are not as bad as they seem. I raised this question in mails, on internal boards and in conversations, and in a presentation <http://www.slideshare.net/ErfGeo/el-presentatie-linked-data-benchmark-council-33040564> at the Linked Data Benchmark Council - Fourth Technical User Community <http://www.ldbc.eu:8090/display/TUC/Fourth+TUC+Meeting,+April+2014>.

>
> So for example, my use case would be to query my linked data store, asking for all early-medieval cultural heritage concepts.
> The questions are then simply formulated as:
> 1. What ontology should I use to describe my 'fuzzy' periods and their temporal bounds?
> 2. How am I to annotate, say, the event of the assassination of Caesar on March 15, 44 BC in linked data?
> 3. What triple stores are able to equate this event with the Roman period?
> 4. Can this kind of reasoning be done using OWL (or would I even want this?)
>
> I have already received quite some very valuable input, some of which I will try to summarize. I must admit that I have not been able to follow up much of their suggestions as of yet. But I already thank the many very helpful contributions.
>

> * Victor de Boer has used the TIMEX vocabulary, but I do not know what kind of components he uses for querying/parsing. His suggestion is also to leave the original time description from the heritage data as is, and include enriched data in Heritage & Location to reason with.
> * Rob Warren made an ontology for Monuments and Graves <http://rdf.muninn-project.org/ontologies/graves.html> and gave a lot of helpful suggestions that cover too much to repeat here for the moment.
> * Milco Wansleeben suggested W3 Time <http://www.w3.org/TR/owl-time/>. I looked into this a bit and it seems that the ontology itself isn't intended for historical events, but for describing documents and web services (although the example used on the page is about the birth of a person).
> * Joop Vanderheiden contributed an ontology based on the Archaeological Base Register to Heritage & Location (not online as of yet)
> * Paul Cripps and Keith May pointed me to CIDOC-CRM, although I suspect the exact temporal descriptions in CIDOC:E50_Date are too loosely described (xsd:string) to be of use
> * Linda van den Brink and others in our Vocabulary pilot group are investigating the Europeana Data Model
> * Gerard Kuys is developing an event ontology for DBpedia
> * I briefly discussed OWLIM support for time BC - I believe he stated that "-0044-03-15"^^xsd:date for Caesar's demise (did I get this right?) should be possible in OWLIM, but I still have to try.
> * Kostis put me on the track of Strabon, a spatio-temporal RDF triple store, but I have only tested the spatial part

>
>
> So to conclude: I received a lot of very helpful information for encoding temporal information, and frankly I'm a bit flustered. At some time I would have to select a solution that should both offer good spatial support (which is a bit rich to be discussed here also), good temporal support and reasoning. I would very much welcome suggestions on this part as well.
>
> Thanks in advance,
> Rein van 't Veer
> Heritage & Location
>
> --
> You received this message because you are subscribed to the Google Groups "Linked Open Data in Libraries, Archives, & Museums" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to lod-lam+u...@googlegroups.com <mailto:lod-lam+u...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to the Google Groups "Linked Open Data in Libraries, Archives, & Museums" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to lod-lam+u...@googlegroups.com <mailto:lod-lam+u...@googlegroups.com>.

[Paul Cripps]

I would suggest working with the CIDOC-CRM; the issue you mention re dates being strings doesn’t have to be limiting. It’s the same kind of scenario with CIDOC CRM when working with the spatial elements. Very open (at present) to the point of having virtually no barriers. So with E47 Spatial Coordinates, it’s fundamentally a string but perfectly possible to slot a GeoSPARQL node in there (so the string contains a Spatial Reference ID (SRID), some geometry and a tag to indicate it’s an OGC WKTliteral). No reason why the same can’t be used with temporal nodes, incorporating a node from some temporal schema.

 

My concern with the use of exact dates in this manner is that we typically don’t know much about ‘dates’. I must confess, I am a prehistorian, so talking about dates in eg the Neolithic seems rather meaningless. Far more important to be able to describe relative chronologies, ie sequences of periods as we know which periods came before/after which others (eg Neolithic occurs directly after Mesolithic and Neolithic occurs directly before Bronze Age, at least in my part of the world) and which form part of others (eg Late Bronze Age is part of the Bronze Age). And we didn’t have a Copper Age to speak of ;-)

 

Same sort of thing applies to site specific periods (aka phases) used to describe activity on archaeological sites. We rarely have any dating of any precision, but do have stratigraphic sequences and various forms of proxy dating (eg through finds or environmental evidence). So again, it’s all about the relative chronology rather than absolute, with only the odd peg to a date range to tie things in; xsd:date seems rather at odds with this to me. There certainly wasn’t a day, a month, a year or arguably a century when the Mesolithic ‘ceased’ and the Neolithic ‘started’; we would need to be a bit more detailed than that and (for a given location) have a timespan where we would all agree we are pretty much certainly in the Mesolithic and a timespan where we would all agree we are pretty much certainly in the Neolithic and a timespan in the middle there representing the transition from one to the other. And some would argue even that is too crude an approximation as culture is actually a continuous not a discreet phenomenon so trying to compartmentalise at any scale is wholly inappropriate. I’ve been harangued for being too reductionist by theoreticians just for data modelling (ie not just using ‘narrative’ but structuring data) and using GIS; I dread to think what would happen if at the Theoretical Archaeology Conference it were to be suggested that assigning literal dates to prehistoric periods is a good idea. Could actually be quite an interesting experience if anyone is up for it…?

 

Now there’s a big spanner in the works… ;-)

 

Stepping away from literal dates and embracing the fuzziness and the relative, a very sensible approach seems to me to be build an ontology of archaeological periods containing all the terms used to describe them, their relationships to one another and their spatial bounds (a period most emphatically being a spatio-temporal phenomena *not* simply a temporal one). Plus temporal bounds where we have some understanding of them and they are useful eg 1939-45 for WWII (in Europe, not the Far East of course). This can then be used to populate eg CIDOC CRM based resources. That way we can use these events for performing querying and reasoning without necessarily the need for literal data values.

 

This aligns with the kind of spatial approaches where it is possible to work with places, some of which are regions, but we may not have exact depictions/locations. So at a very basic level we can say Salisbury is in Wiltshire, Wiltshire is in England, ergo Salisbury is in England. If we factor in relationships such as those found in transport networks (eg adjacent to), we can do some pretty fancy spatial reasoning without needed to know ‘where’ anything is. This can be seen to be akin to the relative chronologies I described above.

 

So Rein, to answer your questions:

1.       CIDOC CRM

2.       As you have a specific date for that example, how about using a temporal schema and classifying (using E55 Type) the E50 Date to indicate the specific domain ontology used.

3.       If you have a start date and end date for the Roman Period (in Rome, of course!) in the same schema as used to represent the E50 from 2. then any system capable of supporting that schema should work. Additionally, if you have recorded a CRM triple to indicate the timespan of the event of the assassination occurs during (P117) the timespan of your Roman Period, you can query for this in any system using basic SPARQL syntax.

4.       Not sure about OWL but keen to know!

 

Also, if you’re looking at EDM, check out the EDM to CIDOC CRM mapping, crucially the bit about space and time:

“EDM includes some concepts from ORE and from Dublin Core. It denotes its own namespace as "ens:". It includes in its own namespace a series of concepts from the CIDOC CRM, and generalizations over CIDOC CRM concept for the purpose of highly general queries against a large body of data. We have created in a graphical form a first draft of a mapping from CRM-FRBRoo to EDM and the Dublin Core properties it reuses. This mapping is complete - except for some CRM properties about structuring time and space EDM does not deal with or has not developed yet.” - http://www.cidoc-crm.org/crm_mappings.html

 

As always, thoughts appreciated. I would love to hear about how others are tackling this issue, both from a philosophical / theoretical perspective and a pragmatic / implementation  perspective.

 

All best,

Paul.

[ZENG, MARCIA]

Hi, Rein,
I am giving a quick suggestion here. I did not follow all the discussions carefully so please forgive me if I am not on the target.

For the historical period, the Art and Architecture Thesaurus has a whole sub-facet:
<styles, periods, and cultures by general era>
It is one of the sub-facet of <Styles and Periods>

You can go from here:
http://www.getty.edu/vow/AATHierarchy?find=AAT+Hierarchies&logic=AND&note=&subjectid=300111078

click on the little hierarchy icon to get the hierarchies of a particular era.

This will be a good start for you.

Every AAT entry has been published as Linked Data. You can get the Semantic View, plus all kinds of RDF serialization options (JSON, RDF, N3/Turtle, N-Triples)

Almost all of the concepts have Dutch already.

Vladimir should be able to pull out this whole facet from the ontology if you ask him.
Hope this is helpful.
Marcia Zeng
________________________________________
From: lod...@googlegroups.com <lod...@googlegroups.com> on behalf of Antoine Isaac <ais...@few.vu.nl>
Sent: Tuesday, April 8, 2014 4:12 PM
To: lod...@googlegroups.com
Subject: Re: [LODLAM] Historical time ontologies and parsing in LOD

Hi,

Antoine

To unsubscribe from this group and stop receiving emails from it, send an email to lod-lam+u...@googlegroups.com.

[Robert Warren]

There is an untidy difference between the thing called the “Bronze Age” as a concept and its measurement in some unit (circa 3300BC-600BC, depending on geography). There is also a difference between the labelling of the thing “Bronze Age (3300BC-600BC)” for human visual consumption and the machine readable description [-3300,-600].

Previously we used to mix all of these together and while this seemed a good idea at the time, it is unmanageable with the amount of data that is being generated. Based on previous experiences I would go so far to say that if the information isn’t machine readable it is likely be ignored. To paraphrase a lodlam member: “links not strings”.

Both time-owl[1] and[2] cidoc have pretty much the same set of properties that relate temporal concepts (before, after, during, etc…). There are more than a few ontologies / datasets out there that have created their own timeline using dbpedia or other datasource using these relative properties.

Time-owl can ground a temporal entity into XML datatypes which can be parsed out of the box (eg: xsd;gYear) in plain RDF / SPARQL. This is somewhere near ISO 8601 and is supposed to handle non-gregorian (<1582?) years. A number of system-level libraries do weird things with pre-1970 or 1582 dates, but comparing years as integers is pretty safe. If you want to say that something happened before 600BC but after 3000BC, you can do that now.

I’m keen on this approach since it breaks gracefully until we get a triple store that can merge temporal reasoning and calendaring properly (There’s an idea - anyone want to write a research grant?) Of course, this is all gregorian calendar which isn’t the only game in town - a few people reading this are likely to get all excited when talking about geological time, the year of the serpent and astronomical time. not to mention the ever popular and relaxed Electroweak epoch[3].

That said, you can hedge your bet and keep everyone happy without too much trouble:

If you are a hardcore RDF’er:

<rdf:Description rdf:about=“BronzeAge”>
<rdfs:label xml:lang=“en”>The Bronze Age (Generic)</rdfs:label>
<rdf:type rdf:resource=“http://www.w3.org/2006/time#TemporalEntity”/>
<rdf:type rdf:resource=“http://purl.org/NET/crm-owl##E2.Temporal_Entity“/>
<time:before>
<rdf:Description rdf:about=“EndOfBronzeAge”>
<rdf:type rdf:resource=“http://www.w3.org/2006/time#Instant”/>
<time:inDateTime>
<rdf:Description rdf:about=“EndOfBronzeAgeDate”>
<rdf:type rdf:resource=“http://www.w3.org/2006/time#DateTimeDescription”/>
<time:year rdf:datatype=“&xsd;gYear”>-600</time:year>
<time:inDateTime>
</rdf:Description>
<time:before>
(CIDOC version here…)
</rdf:Description>

If you prefer OWL:

<owl:Class rdf:ID=“BronzeAge”>
<rdfs:label xml:lang=“en”>The Bronze Age (Generic)</rdfs:label>
<owl:unionOf rdf:parseType=“Collection”>
<owl:Class rdf:about=“http://www.w3.org/2006/time#TemporalEntity”/>
<owl:Class rdf:about=“http://purl.org/NET/crm-owl##E2.Temporal_Entity“/>
</owl:unionOf>
(As above)
</owl:Class>

where

<time#before> <owl:sameAs> <crm:P120F.occurs_before>
<time#after> <owl:sameAs> <crm:P120B.occurs_after>
etc…

Interestingly, if you wish to use OWL to narrow down what Bronze age we are talking about:

<rdf:Description rdf:about=“BronzeAgeChina”>
<rdfs:label xml:lang=“en”>The Bronze Age (Generic)</rdfs:label>
<rdfs:subClassOf rdf:resource=“#BronzeAge”/>
<time:before … 700BC>
<time:after … 2000BC>
<gn:locatedIn rdf:resource=“http://www.geonames.org/1814991/about.rdf”/>
</rdf:Description>

A very handy tool is the owl:differentFrom construct:

<#BronzeAgeChina> <owl:differentFrom> <#BronzeAge>

this prevents your definition from being mistaken for something it is definitely not.

If all else fails create your own class or instance, define your own time period exactly as you mean it to be, overload the terms with properties from other ontologies and over-specify temporal elements against other reference points in other databases. This will give you the benefit of having exactly what you want and as the triple store gets smarter, the semantic linkages will enable discovery.

best,
rhw

[1] http://www.w3.org/TR/owl-time/
[2] http://www.cidoc-crm.org/rdfs/cidoc_crm_v5.0.2_english_label.rdfs
[3] http://en.wikipedia.org/wiki/Electroweak_epoch

On Apr 8, 2014, at 5:29 PM, Paul Cripps <pjc...@gmail.com> wrote:

> I would suggest working with the CIDOC-CRM; the issue you mention re dates being strings doesn’t have to be limiting. It’s the same kind of scenario with CIDOC CRM when working with the spatial elements. Very open (at present) to the point of having virtually no barriers. So with E47 Spatial Coordinates, it’s fundamentally a string but perfectly possible to slot a GeoSPARQL node in there (so the string contains a Spatial Reference ID (SRID), some geometry and a tag to indicate it’s an OGC WKTliteral). No reason why the same can’t be used with temporal nodes, incorporating a node from some temporal schema.
>
> My concern with the use of exact dates in this manner is that we typically don’t know much about ‘dates’. I must confess, I am a prehistorian, so talking about dates in eg the Neolithic seems rather meaningless. Far more important to be able to describe relative chronologies, ie sequences of periods as we know which periods came before/after which others (eg Neolithic occurs directly after Mesolithic and Neolithic occurs directly before Bronze Age, at least in my part of the world) and which form part of others (eg Late Bronze Age is part of the Bronze Age). And we didn’t have a Copper Age to speak of ;-)
>
> Same sort of thing applies to site specific periods (aka phases) used to describe activity on archaeological sites. We rarely have any dating of any precision, but do have stratigraphic sequences and various forms of proxy dating (eg through finds or environmental evidence). So again, it’s all about the relative chronology rather than absolute, with only the odd peg to a date range to tie things in; xsd:date seems rather at odds with this to me. There certainly wasn’t a day, a month, a year or arguably a century when the Mesolithic ‘ceased’ and the Neolithic ‘started’; we would need to be a bit more detailed than that and (for a given location) have a timespan where we would all agree we are pretty much certainly in the Mesolithic and a timespan where we would all agree we are pretty much certainly in the Neolithic and a timespan in the middle there representing the transition from one to the other. And some would argue even that is too crude an approximation as culture is actually a continuous not a discreet phenomenon so trying to compartmentalise at any scale is wholly inappropriate. I’ve been harangued for being too reductionist by theoreticians just for data modelling (ie not just using ‘narrative’ but structuring data) and using GIS; I dread to think what would happen if at the Theoretical Archaeology Conference it were to be suggested that assigning literal dates to prehistoric periods is a good idea. Could actually be quite an interesting experience if anyone is up for it…?
>
> Now there’s a big spanner in the works… ;-)
>
> Stepping away from literal dates and embracing the fuzziness and the relative, a very sensible approach seems to me to be build an ontology of archaeological periods containing all the terms used to describe them, their relationships to one another and their spatial bounds (a period most emphatically being a spatio-temporal phenomena *not* simply a temporal one). Plus temporal bounds where we have some understanding of them and they are useful eg 1939-45 for WWII (in Europe, not the Far East of course). This can then be used to populate eg CIDOC CRM based resources. That way we can use these events for performing querying and reasoning without necessarily the need for literal data values.
>
> This aligns with the kind of spatial approaches where it is possible to work with places, some of which are regions, but we may not have exact depictions/locations. So at a very basic level we can say Salisbury is in Wiltshire, Wiltshire is in England, ergo Salisbury is in England. If we factor in relationships such as those found in transport networks (eg adjacent to), we can do some pretty fancy spatial reasoning without needed to know ‘where’ anything is. This can be seen to be akin to the relative chronologies I described above.
>
> So Rein, to answer your questions:
> 1. CIDOC CRM
> 2. As you have a specific date for that example, how about using a temporal schema and classifying (using E55 Type) the E50 Date to indicate the specific domain ontology used.
> 3. If you have a start date and end date for the Roman Period (in Rome, of course!) in the same schema as used to represent the E50 from 2. then any system capable of supporting that schema should work. Additionally, if you have recorded a CRM triple to indicate the timespan of the event of the assassination occurs during (P117) the timespan of your Roman Period, you can query for this in any system using basic SPARQL syntax.
> 4. Not sure about OWL but keen to know!
>
> Also, if you’re looking at EDM, check out the EDM to CIDOC CRM mapping, crucially the bit about space and time:
> “EDM includes some concepts from ORE and from Dublin Core. It denotes its own namespace as "ens:". It includes in its own namespace a series of concepts from the CIDOC CRM, and generalizations over CIDOC CRM concept for the purpose of highly general queries against a large body of data. We have created in a graphical form a first draft of a mapping from CRM-FRBRoo to EDM and the Dublin Core properties it reuses. This mapping is complete - except for some CRM properties about structuring time and space EDM does not deal with or has not developed yet.” - http://www.cidoc-crm.org/crm_mappings.html
>
> As always, thoughts appreciated. I would love to hear about how others are tackling this issue, both from a philosophical / theoretical perspective and a pragmatic / implementation perspective.
>
> All best,
> Paul.
>
>
>
> From: Rein van 't Veer [mailto:rein.v...@den.nl]
> Sent: 08 April 2014 17:50
> To: lod...@googlegroups.com
> Cc: vladimir...@ontotext.com; v.de...@vu.nl; j.vande...@cultureelerfgoed.nl; rwa...@math.carleton.ca; pa...@archaeogeomancy.net; "Wansleeben, m.wansleeben"@arch.leidenuniv.nl; gerar...@ordina.nl; kostis.k...@cwi.nl; Keit...@english-heritage.org.uk; l.vand...@geonovum.nl
> Subject: Historical time ontologies and parsing in LOD
>
> Hello LODLAM,
>
> In an effort to tie together several questions and answers regarding historical time in LOD, I chose this forum as a place as suggested by Vladimir (thanks). My question is as follows: we, from the Heritage & Location project, are to assemble a lot of enriched linked data on cultural heritage institutions throughout the Netherlands. Heritage & Location is a semantic web initiative for the Dutch cultural heritage sector, offering infrastructure, web viewers and tools, business models and crowdsourcing tools.
>

> In some alarming messages, there seems to be a lack of implementations that can properly parse historical time occurences in linked data in order to reason over it, but perhaps things are not as bad as they seem. I raised this question in mails, on internal boards and in conversations, and in a presentation at theLinked Data Benchmark Council - Fourth Technical User Community.

[Simon Spero]

That link will take you straight to the LODE to the ontology.
Note that LODE uses owl-time for it's timey-wimey thing, so all Allen relations apply

Also note that LODE defines properties as subproperties of relevant CIDOC CRM properties.

There's also Ryan Shaw's dissertation at http://aeshin.org/dissertation/ .

There's also Ryan Shaw :-)

Simon

    To unsubscribe from this group and stop receiving emails from it, send an email to lod-lam+unsubscribe@googlegroups.com <mailto:lod-lam+unsubscribe@googlegroups.com>.

    For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Linked Open Data in Libraries, Archives, & Museums" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lod-lam+unsubscribe@googlegroups.com <mailto:lod-lam+unsubscribe@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Linked Open Data in Libraries, Archives, & Museums" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lod-lam+unsubscribe@googlegroups.com.

[Vladimir Alexiev]

Hi Rein!

> In some alarming messages, there seems to be a lack of implementations that can properly parse historical time occurences
> in linked data in order to reason over it, but perhaps things are not as bad as they seem.

Ok, so it seems 4store doesn’t have proper handling of dates. Today in 2014, after all of the “year 2000” brouhaha, it’s anachronistic to see people complaning about C libraries based on the “unix era” (1970) and not being able to handle BC years. Just use a proper implementation of dates.

There are repositories that have proper handling of dates. OWLIM is such, e.g. see
1. Try this at http://vocab.getty.edu/sparql
select * {?x gvp:startDate ?y FILTER (?y < "0001"^^xsd:gYear)}
2. Try this at http://collection.britishmuseum.org/sparql
select * {?x crm:P82a_begin_of_the_begin ?y FILTER (?y < "0001-01-01"^^xsd:date)}}
The oldest date there is 850k years ago ☺

You also see something unfortunate re *date granularity*: in one repo we've used xsd:gYear, in another full xsd:date.
E.g. in ResearchSpace we have encountered some incomplete dates (Rembrandt data from RKD):
https://confluence.ontotext.com/display/ResearchSpace/date+vs+gYearMonth+vs+gYear
so we represented them eg as "1686-12-10"^^xsd:date, "1686-12"^^xsd:gYearMonth, "1686"^^xsd:gYear

SPARQL (http://www.w3.org/TR/sparql11-query/) doesn’t have good support for casting when comparing:
See section 17 Expressions and Testing Values. As far as I understand:
- sec 17.3 Operator Mapping compares only xsd:dateTime (full datetimes): not xsd:date, let alone gYearMonth or gYear
- sec 17.5 XPath Constructor Functions allows casting only from/to xsd:dateTime.
- all examples use xsd:dateTime and NOT xsd:date
- but there is room for a natural extension: sec 17.1 says "SPARQL language extensions may treat additional types as being derived from XML schema datatypes"

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

So you either:
- need to know date granularity and make appropriate queries as above, or
-- but what if different objects in the same repo use different granularity?
- use sparql conversion functions, but then you'd lose in speed (the OWLIM "literal index" is not used on function results), or
- make sure you use some defined "datetime completion" when loading the data.

The datetime completion depends on the semantics of the field: a "begin" field should be completed to "yyyy-01-01T00:00:00Z", an "end" field to "yyyy-12-31T23:59:59:59Z".
And 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.

> What ontology should I use to describe my 'fuzzy' periods and their temporal bounds?

CRM is the right ontology to use. It has the great idea to distinguish:
- E4 Period "sets of coherent phenomena or cultural manifestations bounded in time and space" from
- E52 Time-Span "temporal extent, having a beginning, an end and a duration"
P4 has time-span is just one of the characteristics of E4 Period.
You can say a lot about Periods (cultural characteristics, place, and full Allen temporal arithmetics) even without knowing their time spans.
Many examples were given of archeological or prehistoric periods where it doesn't make much sense to talk about precise time spans.

> CIDOC-CRM, although I suspect the exact temporal descriptions in CIDOC:E50_Date are too loosely described (xsd:string) to be of use

There are enough fields to describe a Time-Span precisely, but there's quite a lot of confusion which ones to use.
You don't use E50_Date (it doesn’t lead to a Time Primitive), nor P79 beginning is qualified by / P80 end is qualified by.
You use P82 at some time within ("outer bounds"), and sometimes P81 ongoing throughout ("inner bounds"),
but you need these as intervals:

In response to an issue I raised in 2011: http://www.cidoc-crm.org/issues.php?id=197
Martin Doerr defined: http://www.cidoc-crm.org/docs/How_to%20implement%20CRM_Time_in%20RDF.pdf
which splits P82, P81 into intervals: P82a&b, P81a&b.
The RDFS is http://www.cidoc-crm.org/rdfs/CRMtime_spans_v1.0.rdfs
So you get 4 dates to describe a time-span (begin/end of the begin/end).

I'd recommend these papers:
- Deducing event chronology in a cultural heritage documentation system (Holmen & Ore, CAA 2009)
An in-depth discussion of the 4-dates model
- Implementing archaeological time periods using CIDOC CRM and SKOS (Binding, ESWC2010)
STAR STELLAR has made a catalog of periods but I think it's more focused on relatively recent times (Tudor, Victorian, etc).
Google "time site:cidoc-crm.org" and you'll find some other interesting resources, e.g.
- A brief explanation of time
http://www.cidoc-crm.org/docs/frbr_oo/frbr_docs/meeting_presentations/10th_meeting_presentations/Allen%20Operators.doc
- An Interval Algebra for Indeterminate Time
http://www.cidoc-crm.org/docs/aaai2000.ps

Furthermore, you can use P3_has_note to add a human-readable label to the time-span.

> 2. How am I to annotate, say, the event of the assassination of Caesar on March 15, 44 BC in linked data?

Here's a Turtle representation, using URL naming as we used in ResearchSpace.

<JuliusCaesar> a E21_Person;
P100i_died_in <JuliusCaesar/death>.

<JuliusCaesar/death> a E69_Death, E7_Activity;
P2_has_type <activity/assassination>;
P14_carried_out_by <MarcusJuniusBrutus>, <GaiusCassiusLonginus>;
P100_was_death_of <JuliusCaesar>; # no need, will be inferred from P100i
P7_took_place_at <Pompei>;
P9i_forms_part_of <RomanPeriod>;
P4_has_time-span <JuliusCaesar/death/date>.

<JuliusCaesar/death/date> a E52_Time-Span;
P3_has_note "Ides of March (March 15), 44 BC";
P82_at_some_time_within "-0044-03-15"^^xsd:date.

- In this case the date is precise, so I have not used P82a&b.
- But if you want to go for xsd:dateTime (since SPARQL only defines comparison of datetimes), you'd do this:
<JuliusCaesar/death/date> a E52_Time-Span;
P3_has_note "Ides of March (March 15), 44 BC";
P82_at_some_time_within "-0044-03-15"^^xsd:date
P82a_begin_of_the_begin "-0044-03-15T00:00:00"^^xsd:dateTime;
P82b_end_of_the_end "-0044-03-15T23:59:59"^^xsd:dateTime;
-- this BTW is a good example why P82a&b shouldn't be sub-props of P82:
here we'll get 3 values for P82, of which the first one is historically accurate, but the other two are artificially completed to datetime.
- See http://personal.sirma.bg/vladimir/crm-graphical/ for very useful "usage scenarios",
and for the class hierarchy (to understand why we have both E69_Death, E7_Activity)

> OWLIM support for time BC - I believe he stated that "-0044-03-15"^^xsd:date for Caesar's demise (did I get this right?)
> should be possible in OWLIM, but I still have to try.

That's right, and see more details above.

> 3. What triple stores are able to equate this event with the Roman period?

The statement P9i_forms_part_of <RomanPeriod> says the assassination happened during the Roman period.
You can then find events in that period by using an approach such as "FR search".
- See these papers for the theory:
Fundamental Categories and Relationships for intuitive querying CIDOC-CRM based repositories (FORTH TR-429, Apr 2012)
New Framework for Querying Semantic Networks (FORTH TR419 2011)
- And these for an implementation (in ResearchSpace):
Implementing CIDOC CRM search based on fundamental relations and OWLIM rules (TPDL 2012)
Large-scale reasoning with a complex cultural heritage ontology (CIDOC CRM) (TPDL 2013)

It's important that the inclusion and Allen relations are on the Period not the Time-Span level,
since you can talk about periods even without knowing date particulars.
This is typically used to express the period/style of some object as "<production> P9i forms part of <period/style>".

> 4. Can this kind of reasoning be done using OWL (or would I even want this?)

You can write queries that access a of <period/style> without using reasoning.
But CRM usually involves rather complex networks, so to access them the FR Search approach is useful.
We've used OWLIM Rules to implement it, thus creating shortcuts or "indexing relations" for more efficient searching.

> ontology based on the Archaeological Base Register

I know of at least 2 archeological ontologies based on CRM: CRMEH and CRMarchaeo.

> At some time I would have to select a solution that should both offer good spatial support
> (which is a bit rich to be discussed here also), good temporal support and reasoning.

I'm currently researching several geo ontologies for the purposes of Getty TGN.
Clearly one of them will be GeoSPARQL, but there will be more. I'll share the results in about a month.

Regarding geo on CRM, look for this paper:
Integration of Coordinate Information in CIDOC CRM (October 2011)
(and attendant illustrations geosparql_4_crmv2.pdf, geosparql_4_crmv2-needsMindJet.pdf)
It gives a good overview of geo ontologies and how to link them to CRM.

And then there is
CRMgeo- Linking the CIDOC CRM to GeoSPARQL (FORTH TR-435, Apr 2013)
but it's too complicated to my taste.

> I would very much welcome suggestions on this part as well.

My suggestion is to go with CRM, because it provides the right foundation for all these things.

Cheers! Vladimir

[Richard Light]

On 09/04/2014 10:08, Vladimir Alexiev wrote:

CRM is the right ontology to use. It has the great idea to distinguish: - E4 Period "sets of coherent phenomena or cultural manifestations bounded in time and space" from - E52 Time-Span "temporal extent, having a beginning, an end and a duration" P4 has time-span is just one of the characteristics of E4 Period. You can say a lot about Periods (cultural characteristics, place, and full Allen temporal arithmetics) even without knowing their time spans. Many examples were given of archeological or prehistoric periods where it doesn't make much sense to talk about precise time spans.

Since you clearly haven't had enough advice yet, here's a link to a draft "Linked Data design pattern" I wrote for recording dates in CRM:

http://light.demon.co.uk/wordpress/?p=600

The only advantage it has over Vladimir's excellent advice is that it is short. :-)

Richard

--
Richard Light

[Simon Spero]

Extra warning: CRM-* in rdfs is in...rdfs. This means that it is not in OWL 2.

If you try to import the rdfs as owl using owlapi based tools like protege, you are going to run in to some issues, as cheat mode currently makes some incorrect guesses. I am trying to tune the fixer to avoid some of the misread cues.

There is an unofficial  owl2-dl version via purl.org/NET;  I'm not sure how closely it tracks ICM drafts.

Also, Pat Hayes's report on time has a little discussion of some of the niceties of using intervals to represent imprecisely known times (meets becomes overlaps, etc.).

Radiocarbon dates may map to time intervals differently based on improved calibration curves, discovery of contamination issues at a lab, etc. 

Combination of evidence sources may give smaller empirical intervals,and logical reasoning may impose a partial order within the intervals.

Temporal reasoning can become quite complicated if you let it (see e.g. Baker,Eccleston & Tennant 2506). 

This paper by Bob Schrag gives some good advice;
http://stids.c4i.gmu.edu/papers/STIDSPapers/STIDS2012_T03_Schrag_BestPracticeTemporalReasoning.pdf

See also:
http://stids.c4i.gmu.edu/papers/STIDSPapers/STIDS2012_T13_Schrag_InferenceInTemporalRDF.pdf

Naming time periods can be even more complicated; to British people, the second world war began on the 3/9/39. Poles might disagree; my fiancée's grandparents and mother escaped Prague the night before the Nazis rolled in; 1/9 seems a bit late.

Dates for the term "bronze age" may be as much an artifact of discoverers of  artifacts as anything else. Context is key when interpreting assigned labels.

--

You received this message because you are subscribed to the Google Groups "Linked Open Data in Libraries, Archives, & Museums" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lod-lam+u...@googlegroups.com.

[Vladimir Alexiev]

The owl2-dl version via purl.org/NET is IMHO dead.

> in rdfs. This means that it is not in OWL 2.

Simon, could you please clarify, I thought RDFS is a subset of OWL 2?

(The CRM SIG version is RDFS but it need to be more since it needs at least owl:inverseOf and owl:Symmetric.

The ECRM version has those, but also has owl:Restrictions which many don't accept, so there's a rift there.

So I wrote some simplification scripts that can remove the controversial stuff but keep owl:inverseOf and owl:Symmetric, see https://github.com/erlangen-crm/ecrm/blob/master/ecrm-simplify.xq)

Once I understand your concern, I'll try to post it on the CRM SIG mlist. 

[Simon Spero]

OWL 2 is almost an extension of RDFS. However, OWL divides properties into Object Properties, Data Properties, and Annotation Properties.  OWL-2 DL requires that no property be an instance of more than one of these types. 

 Although the RDF Semantics for OWL 2 include definitions that make rdf:Property a subClass of owl:ObjectProperty (which itself is a subClass of rdf:Property), the direct semantics do not include such a rule.  

To make matters worse, the rdf to owl mapping specification only covers OWL-2 DL, so any OWL-2 toolkit that encounters an rdf:Property that doesn't also have a more specific property type attached must either reject the document, or attempt to apply heuristic fixes to let the document parse. 

To make matters even worse, OWLAPI (the library used by protege and most OWL-2 tools) has a bug in the way it attempts to handle these properties. If it sees that a property range is specified as a class, it will guess that the property is an object property.  

If it sees a range that specifies a datatype, it will guess data property.  If it doesn't have any other information it will default to annotation property, because annotation properties are ignored by the OWL2 Direct Semantics, so it's a safe guess. 

Unfortunately, when it sees a domain for an untyped property, it will default to guessing annotation property; depending on order, you can end up with an IRI that is an AnnotationProperty that has an AnnotationPropertyDomain, with an identically named ObjectProperty that has ObjectPropertyRange. 

Similar problems happen with rdfs:subPropertyOf triples. 

To make matters even worse, I'm supposed to be fixing this tonight as it is a blocker on the release of the next version :-)

Simon

p.s.

Using  SymmetricObjectProperty is forbidden by OWL-2 EL.  

Using TransitiveObjectProperty is forbidden by OWL-2 QL. 

They're OK in OWL-2 RL, as long as you meet the other OWL-2 RL requirements. 

Using Symmetric, Transitive properties is forbidden in OWL-2 DL. 

To understand more the OWL-2 sub profile, I strongly recommend reading this introduction written by Markus Krötzsch  for the reasoning web summer school 2012:  http://korrekt.org/page/OWL_2_Profiles .

Slides are here:  http://www.kr.tuwien.ac.at/events/rw2012/teaching-material/RW12-Tutorial-Kroetzsch.pdf

Slides contain adorable pictures of baby owls. 

 

[Amanda Xu]

>They're OK in OWL-2 RL, as long as you meet the other OWL-2 RL requirements. 

Why not go with OWL-2 RL then?  

Cheers,

Amanda

[Simon Spero]

I would expect Vladimir to be unconsciously  thinking in RL, since that's roughly the profile that OWLIM is built to (see e.g.  http://www.ontotext.com/rdfs-rules-owl ). 

There are tradeoffs in expressivity, completeness, and performance for certain tasks; many database tasks are easier in QL, classification is faster in EL; RL is the easiest to fit to a rule based implementation.

Some of the fastest reasoners try to figure out what profile an OWL 2-DL ontology fits, and try to  fit the right sub-reasoner to the ontology, use multiple reasoners, and/or transform the ontology to give sound results with different levels of completeness. 

 A good example is TrOWL - http://trowl.eu/ ;  

Stardog is another example, with the reasoner and the database developed in concert  -see http://docs.stardog.com/owl2/#sd-Introduction  

The introduction and tutorial by  Krötzsch I cited above is a good place to get started on the reasoning behind the profiles; the W3 spec is quite opaque. 

OWL DL and OWL full are limiting enough;  making things less expressive doesn't improve things.  

[This is starting to drift away from temporal logic  - a separate thread might be a good idea] :)