Re: [pelagios] Digest for pelagios-project@googlegroups.com - 2 updates in 1 topic

[Merrick Lex Berman]

hi,

Might we consider to use tileJson?
https://github.com/mapbox/tilejson-spec
Apparently Mapbox uses it, and those people are pretty smart.
I also noticed an historical use-case in Japan:  http://dsr.nii.ac.jp/geography/tilejson/

-lex

BCC to Leif, since I expect this message to bounce from the listserve.


On 7/12/2014 11:12 AM, pelagios...@googlegroups.com wrote:

  Today's topic summary

Group: http://groups.google.com/group/pelagios-project/topics

• Digest for pelagios...@googlegroups.com - 1 update in 1 topic [2 Updates]

 Digest for pelagios...@googlegroups.com - 1 update in 1 topic

Robert Sanderson <azar...@gmail.com> Jul 11 08:08AM -0700  

There is a GeoJSON-LD profile that was created by Sean Gillies, that
thereby maps into RDF.
 
http://geojson.org/vocab
 
HTH,
 
Rob
 
 
geoJSON in Pleiades
 
--
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305


 

Ethan Gruber <ewg4...@gmail.com> Jul 11 02:06PM -0400  

Hypothetically, the geojson:geometry property could contain the following
literal: '{"type": "Polygon", "coordinates": [[[16.0, 41.0], [16.0, 41.5],
[15.5, 41.5], [15.5, 41.0], [16.0, 41.0]]]}'. Correct?
 
 
On Fri, Jul 11, 2014 at 11:08 AM, Robert Sanderson <azar...@gmail.com>
wrote:
 


 

--
ॐ - Lex Berman
desk (617) 496-9439 - info
Web Services Manager, Center for Geographic Analysis
watershed: Alewife Brook > Mystic River > Boston Harbor > Atlantic Ocean

[Robert Sanderson]

Hi Ethan,

I don't think geometry would contain a literal, but the object as you have quoted.

See the example at:

    https://raw.githubusercontent.com/geojson/geojson-ld/master/examples/us-statehood/us-statehood.geojson

Rob

[Ethan Gruber]

I have been following that and a few other examples.  I have come up with the following: http://admin.numismatics.org/nomisma/id/ionia.jsonld

I threw it into a JSON parser, and it does parse, and I put it into the JSON-LD playground (http://json-ld.org/playground/), and took a look at the resulting triples. It appears that the JSON-LD + geoJSON upholds all the the necessary semantic meaning. Did I construct this model correctly?

The source is RDF/XML, so the geoJSON does have to be preserved as a literal with some property--whether osgeo:asGeoJSON or something else.

Sorry if this thread is off topic for the Pelagios list. I have no idea where else this conversation should go.

--

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/d/optout.

[Robert Sanderson]

TileJSON isn't JSON-LD so it wouldn't survive a round trip through an RDF parser, unfortunately.  The advantage of GeoJSON-LD is that it will round trip properly.  As to its appropriateness for the use case here, I leave that to others.

Rob

[Robert Sanderson]

It looks correct to me! :)

I would suggest putting a link to it in the github issues and see if Sean replies.  He's normally very good at responding.

Rob

[Merrick Lex Berman]

hi,

Thanks Rob.  I am just looking into geojson-ld.  Seems very promising.   The properties shown in the geojson-time example seem to be what we need, for the most part:
https://github.com/geojson/geojson-ld/blob/master/contexts/geojson-time.jsonld

am I correct to think that each object allows for a time "interval" to represent when the object lifespan occurs,
and that there can be multiple geometries over time representing the object with their own unique start-stop values?

    context {

    "Instant": "http://www.w3.org/2006/time#Instant",
    "Interval": "http://www.w3.org/2006/time#Interval",

   }

    geometry {

    "id": "@id',
    "properties": "geojson:properties",
    "start": "http://www.w
3.org/2006/time#hasBeginning",
    "stop": "http://www.w3.org/2006/time#hasEnding",
    "title": "http://purl.or
g/dc/terms/title",
    "type": "@type",
    "when": "geojson:when"

   }

It is not exactly how our China data is structured, but if I understand it correctly, I can adapt when serializing into this geojson-ld format.

best,
-lex

[Simon Rainer]

Hi Ethan,

 

I’m just back from my vacation & trying to catch up with all the traffic that has been piling up in my inbox.

 

This JSON-LD sample looks great! I wonder if we can somehow find a way to harmonize this with the RDF we’re using for place metadata in Pelagios. Obviously, such things can always be cross-walked into each other. But the more we can avoid the need for cross-walks, the better. So I’m really interested in your thoughts on our current state of affairs & whether we can tune here and there in order to make our data more interchangeable.

 

Here’s are two samples (courtesy of Tom!) that show what we ended up with after a few iterations:

https://github.com/paregorios/syriac-gazetteer-rdf/blob/master/output/alternative3.ttl

https://github.com/paregorios/syriac-gazetteer-rdf/blob/master/output/pleiades3.ttl

 

Obviously, these samples still use an “asGeoJSON” property with a literal object (which, as you pointed out, is probably not the clean way to do it). So one thing I think we should do, I guess, is change according to your recent example.

 

But I was also wondering about the other metadata:

·         You are using SKOS for the labels, whereas we’re using a property from the Pleiades namespace. Obviously, SKOS is much more of a “standard” vocabulary. On the other hand though, we stuck to the Pleiades property because it would (a) give us more freedom to add things like timestamps/periods and/or bibliographic source info for each name individually where appropriate; and (b) it captures the semantics of a geographic name explicitly. (Although the latter thing is probably less of an issue.)

·         Do you think skos:definition is preferable over dcterms:description (which is what we are using)?

·         I see you are using skos:exactMatch and skos:relatedMatch to point to other “gazetteers” (DBpedia & Pleiades). In our case we’ve ended up with skos:closeMatch instead. I think extending that recommendation to allow skos:exactMatch where appropriate makes total sense (and would help us get our cross-gazetteer links more tightly organized in the long run) – so I think I want to include that in Pelagios also. But I wonder about the use of closeMatch vs. relatedMatch. @All: any thoughts?

 

Cheers,

Rainer

[Ethan Gruber]

Hi Rainer,

We are using SKOS properties because nomisma is a thesaurus of all types of numismatic concepts, not a geographic gazetteer. It just so happens that two types of concepts (mints and regions) might have geographic components. So nm:rome has a skos:prefLabel of "Rome," but we haven't decided whether we would give the geo:SpatialThing of nm:rome#this a label, or what property we'd use for the label (I've been recommended to use dcterms:title, but rdfs:label would also work). Our model may evolve to include different names or boundaries over time for geographic concepts, but we are keeping it as simple as possible at the moment.

And closeMatch vs. relatedMatch: Either could work, but there's a greater level of subjectivity in choosing between these two properties than choosing between related and exact. By definition, all closeMatches are relatedMatches, but not vice versa. Again, I want to keep things as simple as possible and avoid more granular approaches to matching concepts. I'd want to implement either closeMatch or relatedMatch in the system, but not both.

Ethan

[Leif Isaksen]

Having thought about this a bit, I think I agree with Ethan that make
sense to implement to closeMatch and not relatedMatch. I can't think
of a gazetter-alignment situation in which I would want to use the
latter but not the former. (I can think of other cases when I'd want
to use relatedMatch though but it's more of a 'seeAlso', which isn't
quite what we're aiming for).

Cheers

L.

[Simon Rainer]

Hi Ethan,

 

in our case, we’re using http://geovocab.org/spatial.html#Feature instead of geo:SpatialThing (again modeled after Pleiades). Do you have any thoughts about the difference between those? (I assume geovocab:Feature *may* be a subclass of geo:SpatialThing. At least it would make sense I guess – but frankly I could not find an indication of this in the docs.) As for the rest, we’re using dcterms:title (description, etc.) rather than rdfs:label.

 

<I'd want to implement either closeMatch or relatedMatch in the system, but not both.>

 

Totally agreed. I also would want to implement either one or the other in Pelagios. In our case, the choice of closeMatch over relatedMatch was really only based on the verbal definition of closeMatch (“used to link two concepts that are sufficiently similar that they can be used interchangeably in some information retrieval applications”). Another difference is also that exactMatch is a subproperty of closeMatch, which also seems handy (and which isn’t the case for relatedMatch).

[Elizabeth Fentress]

I've asked Leif, but want to ask the whole list - when you are linked
to a dynamic site like Fasti Online shouldn't you periodically update
the links? Could this not be automated?

[Stuart Eve]

Hi Lisa

This is a Fasti side thing, and they are currently being automated, we are just checking with Rainer whether the new format of the data is suitable for ingestion in the new API.

Stu

Stuart Eve

L - P : Archaeology

stua...@lparchaeology.com

L - P : Archaeology is the trading name of L - P : Heritage LLP  Registered in England and Wales OC366545
Registered office address: Amelia House, Crescent Road, Worthing, BN11 1QR

[Elizabeth Fentress]

Cool. Thar is great. Mike has been tellling me about automatic upgrading which would be vital for sustainability.