- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Tue, 27 May 2014 12:58:49 +0200
- To: Karl Grossner <karlg@stanford.edu>
- Cc: Raphaël Troncy <raphael.troncy@eurecom.fr>, Krzysztof Janowicz <janowicz@ucsb.edu>, LocAdd W3C CG Public Mailing list <public-locadd@w3.org>, Pascal Hitzler <pascal.hitzler@wright.edu>, Ben Adams <adams@nceas.ucsb.edu>, Makx Dekkers <makx@makxdekkers.com>, Simon Cox <Simon.Cox@csiro.au>
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.
Received on Tuesday, 27 May 2014 10:59:33 UTC