RE: space and time

Thank Makx (and Hi again!)

Yes – this is largely how I recall it too. I was involved in DC for a shorter period than Makx, so would defer to his account anyway.

Regarding

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.

Yes. The challenge of dealing with ‘structured values’, particularly for space and time was alive from early on, with the constraint of trying to jam it into text strings.

For time there was always ISO 8601 to fall back on (which underlies the XSD temporal types) and most software libraries can deal with parsing that.
But for space, and space-time, the world is yet to converge on a common solution. I developed DCMI Box and Point prior to getting involved in the GIS community, so they suffer from the same naivety that always appears when someone without a strong backgrounds in geospatial or cartography proposes a solution for coordinates and geometry ☹.

The issue is that even the simplest geometry (a single position or point) requires between 3 and N pieces of information, where N could be as much as 20 in order to fully define a coordinate reference system locally which really does happen sometimes. There are specific relationships between them, but the labels and semantics are not even common for all cases (e.g. latitude-longitude vs easting-northing, depending on the coordinate reference system used, for example – there are around a thousand of these in the standard databases[1], and note that ‘southing-westing’ is used in some places even!). Ubiquitous GPS has pushed us all closer to a single standard for the information than ever before (but not the format), but still there are legal requirements and common conventions to use other systems in many places in the world (e.g. UK National Grid), so it is not clear that just saying ‘it is WGS84 and tough luck to everyone else’ is acceptable. A key point is that the individual items are not independent of each other – it is really one piece of information, but is a vector and thus has internal structure. So the standard RDF approach of putting everything in separate literals would require a very complex structure to track all this, which would probably fail to pass the laugh-test for the common case.

My sense is that the closest we have to a useable standard for geometry is WKT. This ticks enough of the boxes – it is a text-based microformat that allows the CRS to be indicated, and doesn’t require escaping to embed in a text field. Like any microformat it does need a special parser, but there a few of these around[2], and since even hard-core RDF types accept a microformat for time, then why not space?

Simon

[1] http://www.epsg-registry.org/

[2] http://en.wikipedia.org/wiki/Well-known_text#RDBMS_Engines_that_provide_support


From: Makx Dekkers [mailto:mail@makxdekkers.com]
Sent: Wednesday, 28 May 2014 6:10 AM
To: 'Andrea Perego'; 'LocAdd W3C CG Public Mailing list'
Subject: 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/


>

> On Sun, May 25, 2014 at 6:29 PM, Karl Grossner <karlg@stanford.edu<mailto: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


> >

> > 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)

> >

> > 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

> > www.kgeographer.org<http://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: raphael.troncy@eurecom.fr<mailto:raphael.troncy@eurecom.fr> & raphael.troncy@gmail.com<mailto:raphael.troncy@gmail.com>

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

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

> >> Web: 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/


>

> ----

> 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.

Received on Tuesday, 27 May 2014 23:59:00 UTC