RE: space and time

 

In response to Andrea’s request, I did some digging in my memory and archive on the ideas that led to the definition of the coverage element in Dublin Core.

 

A very early discussion (1997) is recorded at http://dublincore.org/documents/coverage-element/. 

 

The definition then read:

 

The Coverage element describes the spatial and temporal characteristics of the object or resource and is the key element for supporting spatial or temporal range searching on document-like objects that are spatially or temporally referenced. Coverage may be modified by spatial or temporal qualifiers.

 

A resource may have both spatial and temporal coverages, or just one of the two, or none. This element may be used in describing resources from many different fields, e.g., archaeology, art, cartography, geography, geographic information systems, medicine, natural sciences, etc. - any field that deals with georeferenced information, spatial data, or temporal data. Thus for example, resources describing the Grand Canyon of the United States include text, maps, music (e.g., Ferde Grofe's Grand Canyon Suite), statistics (e.g., number of visitors per year), works of art (such as the panoramas that appear in the 1882 publication, "Atlas to accompany the monograph on the Tertiary history of the Grand Canon district"), etc.; and each could use Coverage - Spatial and in some cases Coverage - Temporal.

 

Spatial information may be given in numeric form (e.g., degrees of latitude) or as text. Temporal information may also be given in numeric form or as text. Numbers are preferred. If scheme is not given, none is assumed. No defaults are assumed.

 

Please note that that was a time when people were still thinking mostly about putting metadata in the META tag of HTML. RDF was just being drafted but it would be some time before that was considered a better way to express metadata.

 

So the idea in 1997 was that there could be several aspects of time and place related to a resource. Those aspects were lumped together in a general purpose bucket that could be further specialised using ‘qualifiers’. A couple of years later, when RDF became the expression of choice for Dublin Core metadata, the original 15 elements were retrofitted into a set of properties with supporting classes conforming to the RDF model.

 

In that process, it was decided that the definition of coverage as a union of temporal and spatial characteristics (jurisdiction was added in the comment in 1999) required the creation of a composite class dcterms:LocationPeriodOrJurisdiction to provide backward compatibility with existing usage. At the same time, the more precise subclasses dcterms:Location, dcterms:Period and dcterms:Jurisdiction were created together with two sub-properties dcterms:spatial and dcterms:temporal to allow for more precise use. In fact, the more precise use was encouraged. In effect, there were calls to deprecate the use of dc:coverage although this was never made explicit in order not to upset the implementations that were based on the mixed usage.

 

I also need to note that some of the more ‘semantically oriented’ people in the DCMI community around 2003-2004 expressed a strong opinion that the lumping together of two very different dimensions had been a big mistake, because it made automated processing very hard.  

 

The ‘structured values’ DCMI Box, DCMI Point  and DCMI Period were intended to provide a method for recording simple structured data in text strings; again, this was intended for use in string-based, META-tag, ‘simple’ Dublin Core. The approach was abandoned in favour of using RDF-based methods; however, I don’t think these DCMI Recommendations were ever formally retired or deprecated.

 

Simon, as the author of these structured value definitions, may have a more precise recollection of how this came about.

 

Hope this helps.

 

Makx.

 

 

 

> -----Original Message-----

> From: Andrea Perego [mailto:andrea.perego@jrc.ec.europa.eu]

> Sent: Tuesday, May 27, 2014 12:59 PM

> To: Karl Grossner

> Cc: Raphaël Troncy; Krzysztof Janowicz; LocAdd W3C CG Public Mailing

> list; Pascal Hitzler; Ben Adams; Makx Dekkers; Simon Cox

> Subject: Re: space and time

> 

> Thanks a lot for sharing the draft, Karl.

> 

> I've just finished reading it, and I have a couple of questions, if I

> may.

> 

> 1. In the draft (page 11) you point out the relationship between the

> notions "setting" and context. I wonder whether you are considering in

> you design pattern the possible integration of the (spatio-temporal)

> Setting ontology with other context models, as the PROV ontology.

> 

> 2. I wonder whether you have any plans to investigate mappings of the

> Settings ontology to other ones, whenever relevant (e.g., as done in

> PROV with Dublin Core [1]). This would give the ability to convert

> existing data, using other vocabularies, into the Settings

> representation (and vice versa), which would be beneficial to data

> interoperability and re-use. This may also help address use cases

> which may require different levels of complexity on how a "setting" is

> modelled (and thus using different vocabularies). And this triggers

> another question: do you plan to include in your design pattern the

> possibility of supporting different levels of complexity? (the example

> is again the PROV ontology, and their notion of "starting point",

> "expanded", and "qualified" terms)

> 

> 3. In Figure 1 (page 17), the set:Period class has a unary

> relationship :composedOf, which is however missing from the set:Place

> class. Is this intentional?

> 

> On a different note, I think it would be beneficial to understand the

> design patterns behind existing and widely used vocabularies, such as

> Dublin Core, which defined a generic property dct:coverage and a

> generic class dct:LocationPeriodOrJurisdiction, and related

> specialisations (dct:spatial, dct:Location; dct:temporal,

> dct:PeriodOfTime; dct:Jurisdiction), as well as encoding schemes for

> points, bboxes and periods (now "deprecated").

> 

> @Makx, @Simon, I wonder whether you can give any insight on the design

> choices made in Dublin Core when modelling these notions.

> 

> Thanks!

> 

> Andrea

> 

> ----

> [1] <http://www.w3.org/TR/prov-dc/> http://www.w3.org/TR/prov-dc/

> 

> On Sun, May 25, 2014 at 6:29 PM, Karl Grossner < <mailto:karlg@stanford.edu> karlg@stanford.edu>

> wrote:

> > Krzysztof, Raphaël -

> >

> > Academic publication time-frames drive me crazy. I have placed an

> excerpt from our chapter-in-review on my web site so list members who

> have an interest can read it. The chapter is about Linked Data for

> historical gazetteers and the pattern discussion comes in Section 3.

> As Krzysztof says, it is an informal introduction.

> >

> >    <http://kgeographer.com/assets/GrossnerJanowiczKessler_excerpt.pdf> http://kgeographer.com/assets/GrossnerJanowiczKessler_excerpt.pdf

> >

> > This discussion is of great interest. Yes, there is now an effort at

> a new GeoJSON-LD standard, and I have co-instigated getting time into

> it (not into core GeoJSON; that idea has been rejected by its keepers).

> >

> > I should also note my recent work with Elijah Meeks on Topotime

> ( <http://dh.stanford.edu/topotime> http://dh.stanford.edu/topotime)

> >

> > People's views about the urgency of somehow joining spatial and

> temporal seem to vary depending on the use cases they deal with the

> most. I work in historical applications and see the joining as

> essential.

> >

> > Regarding the observation that any data _could_ have a temporal

> dimension so why favor spatial, I would say this: it's not about

> adding temporality to widget data, it's about the opportunity to

> include temporal with spatial if you're representing widget locations.

> >

> > The location of a thing or event/period is in fact spatial and

> temporal whether or not we care about both aspects in a given

> situation. A general data model should account for the essential

> characteristics of what it models! In the case of GeoJSON-LD, a

> Feature will have an optional "when" object at the same level as the

> "geometry" object. Existing software that parses GeoJSON will ignore

> the "when" (as well as the @context), but applications can be written

> to process it.

> >

> > I'm not thrilled with how GeoJSON-LD is shaping up but do consider

> it making time a co-equal aspect with space in answers to "where?" a

> significant step forward.

> >

> > cheers, Karl

> >

> >

> > ------------------

> > Karl Grossner, PhD

> > Digital Humanities Research Developer

> > Stanford University Libraries

> > Stanford,CA US

> >  <http://www.kgeographer.org> www.kgeographer.org

> >

> >

> > ----- Original Message -----

> >> Dear Krzysztof,

> >>

> >> > If you are interested in a tight integration of space and time,

> we are

> >> > currently working on a so-called 'settings' ontology design

> pattern that

> >> > does exactly that. It was developed during the last Geo-VoCamp in

> Santa

> >> > Barbara in March 2014. We also have a more informal piece about

> this

> >> > that is currently under review (I am cc-ing Karl Grossner in case

> he

> >> > wants to share the draft)

> >>

> >> Are you saying that this work is being currently peer-reviewed? I

> would

> >> definitively be interested in reading the draft and/or the summary

> of

> >> the March Geo-VoCamp (any pointers?) but I understand you might not

> be

> >> able to share it just right now.

> >> Best regards.

> >>

> >>    Raphaël

> >>

> >> --

> >> Raphaël Troncy

> >> EURECOM, Campus SophiaTech

> >> Multimedia Communications Department

> >> 450 route des Chappes, 06410 Biot, France.

> >> e-mail:  <mailto:raphael.troncy@eurecom.fr> raphael.troncy@eurecom.fr &  <mailto:raphael.troncy@gmail.com> raphael.troncy@gmail.com

> >> Tel: +33 (0)4 - 9300 8242

> >> Fax: +33 (0)4 - 9000 8200

> >> Web:  <http://www.eurecom.fr/~troncy/> http://www.eurecom.fr/~troncy/

> >>

> >>

> >

> >

> 

> 

> 

> --

> Andrea Perego, Ph.D.

> European Commission DG JRC

> Institute for Environment & Sustainability

> Unit H06 - Digital Earth & Reference Data

> Via E. Fermi, 2749 - TP 262

> 21027 Ispra VA, Italy

> 

>  <https://ec.europa.eu/jrc/> https://ec.europa.eu/jrc/

> 

> ----

> The views expressed are purely those of the writer and may

> not in any circumstances be regarded as stating an official

> position of the European Commission.