- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Sat, 07 Jun 2014 01:50:43 +0200
- To: LocAdd W3C CG Public Mailing list <public-locadd@w3.org>, Karl Grossner <karlg@stanford.edu>, Pascal Hitzler <pascal.hitzler@wright.edu>, Ben Adams <adams@nceas.ucsb.edu>
Just to note two recent documents relevant to the discussion in this thread. 1. The report about the Joint W3C/OGC LGD'14 Workshop, which also summarises the issues discussed there on the representation of space and time: http://www.w3.org/2014/03/lgd/report 2. The draft of the joint W3C/OGC Geo Data on the Web Working Group Charter. Consolidating the W3C Time Ontology and moving it to the Recommendation track is one of the foreseen deliverables. http://www.w3.org/2014/05/geo-charter Cheers, Andrea On Thu, May 29, 2014 at 5:26 PM, Andrea Perego <andrea.perego@jrc.ec.europa.eu> wrote: > Makx, Simon, > > Thanks a lot for this enlightening overview on how space and time are > modelled in Dublin Core, and the motivations behind it. > > I have the impression that this thread highlighted many of the key > issues concerning the representation of time and its relationship to > space. For future reference, I started drafting a page in the LOCADD > wiki to record the main points discussed in the thread: > > https://www.w3.org/community/locadd/wiki/Space_and_Time > > All what is included in the page is from publicly available resources. > However, please let me know if you prefer that any content and/or > conversation is not recorded there. > > Of course, everybody is more than welcome to revise and extend the document. > > Cheers, > > Andrea > > > On Wed, May 28, 2014 at 1:57 AM, <Simon.Cox@csiro.au> wrote: >> 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 L. >> >> >> >> 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> >> >>> 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 >> >>> > >> >>> > >> >>> > ----- 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 & 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. > > > > -- > 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. -- 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 Friday, 6 June 2014 23:51:29 UTC