Pelagios gazetteer "interconnection format" - feedback requested

[Simon Rainer]

Dear list,

 

just a small reminder for anyone (especially those who have taken part in our Gazetteer Workshop at ISAW in September :-) to check the draft of our “Gazetteer Interconnection Format”. Any feedback would be greatly appreciated!

 

https://github.com/pelagios/pelagios-cookbook/wiki/Pelagios-Gazetteer-Interconnection-Format

 

Does this meet your understanding of what we discussed in New York? Do you see any errors/issues/gaps?

 

Question specifically for the gazetteer partners: will is this work for you as a format to export your data? Is the Wiki page sufficient information you need to get started?

 

Cheers,

Rainer

 

 

RAINER SIMON

Scientist

Safety and Security Department

Information Management

 

AIT Austrian Institute of Technology GmbH

Donau-City-Strasse 1  | 1220 Vienna  | Austria

T +43 664 2351792 |  F +43 50550-4150

rainer...@ait.ac.at |  http://www.ait.ac.at

 

FN: 115980 i HG Wien  |  UID: ATU14703506

http://www.ait.ac.at/Email-Disclaimer

 

[Karl Grossner]

Dear Rainer, all -

I think the use of DCMI for temporal attributes of Name and Location is too simple, or will be over time. For example, allowing a range for start and end seems like a minimal upgrade, reflecting a simple pattern in widespread use (including in the models discussed so far for both the PeriodO and Topotime projects). Algorithms for computing over such things exist and are likely to make their way into software soon.

Is it possible that the allowed value for "start" and "end" can be another dcterms:temporal range with its own start and end? It does seems unlikely existing systems designed to parse dcmi temporal expressions would handle that.

As we said at the meeting, the timing of both PeriodO and Topotime work is not aligning perfectly with Pelagios' immediate requirement for a core spec. But then, if none of the temporal values extant in Pleiades, CHGIS, and PastPlace have such ranges, this is readily deferred.

Elijah and I expect to make our emerging Topotime spec public, for comment and open development, in mid-November. We look forward to discussing how and whether the Pelagios baseline model may one day support it (or a subset) along with DCMI and PeriodO.

best

Karl

------------------
Karl Grossner, PhD
Digital Humanities Research Developer
Stanford University Libraries
Stanford,CA US
www.kgeographer.org

---

--
You received this message because you are subscribed to the Google Groups "pelagios" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pelagios-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Simon Rainer]

Hi Karl,

 

another really good & important point! Yes, I agree that this seems like a minor upgrade that reflects a common usage pattern.

 

Frankly, I don’t know what values for start and end are permissible in the DCMI Period scheme. But it seems pretty relaxed about it (which is obviously a  good AND a bad thing ;-). At least in the docs, there are examples which simply state “Cambrian period” as a start date, and “Geological timescale” as a scheme (!). Since there’s no off-the-shelf parser for DCMI anyway (and it’s actually a pretty trivial thing), I’m inclined to maybe go with your suggestion of nesting ranges…

 

What’s your roadmap for PeriodO/Topotime? Are you considering to define a scheme that could be used with dcterms:temporal eventually? I guess it’s really just about finding a proper name/shorthand for the scheme, and then defining what’s allowed in the start, name and end fields. Then we could have something like:

 

dcterms:temporal “start=[periodo-style range expression]; end=[periodo-style range expression]; scheme=periodo; name=optional name” ;

 

Cheers,

Rainer

[Karl Grossner]

I've given a misunderstanding -- PeriodO is the developing work of Adam Rabinowitz, Ryan Shaw and Eric Kansa. I am an interested observer only. I mention that work only to say they use the same 'optional range for start and end' pattern Elijah and I use as one core construct for Topotime - and that pattern has been the basis of several algorithms for computing intersects, etc.

Elijah Meeks and I are developing Topotime, which among other things permits a few more parameters in timespan definitions: for within/throughout, duration, cyclical time, etc. -- we will make that public (and open development) by mid-November. The spec is nearly fixed, so we'll aim to share an advance look sooner.

Karl

---

[Simon Rainer]

Hi Karl,

 

< I've given a misunderstanding -- PeriodO is the developing work of Adam Rabinowitz, Ryan Shaw and Eric Kansa. >

 

Ah, yes indeed – I should have remembered this :-(

 

Anyways: getting a sneak peek at the spec will be very helpful for us!

[elton barker]

hi Karl,

Leif and I will be coming over to Stanford for the Hestia2 event, so we're looking forward to getting a sneak preview of Topotime!

cheers

elton