{"action":"created","issue":{"url":"https://api.github.com/repos/LinkedPasts/lp-network/issues/2","repository_url":"https://api.github.com/repos/LinkedPasts/lp-network","labels_url":"https://api.github.com/repos/LinkedPasts/lp-network/issues/2/labels{/name}","comments_url":"https://api.github.com/repos/LinkedPasts/lp-network/issues/2/comments","events_url":"https://api.github.com/repos/LinkedPasts/lp-network/issues/2/events","html_url":"https://github.com/LinkedPasts/lp-network/issues/2","id":321307102,"number":2,"title":"Reification time","user":{"login":"kgeographer","id":1753945,"avatar_url":"https://avatars3.githubusercontent.com/u/1753945?v=4","gravatar_id":"","url":"https://api.github.com/users/kgeographer","html_url":"https://github.com/kgeographer","followers_url":"https://api.github.com/users/kgeographer/followers","following_url":"https://api.github.com/users/kgeographer/following{/other_user}","gists_url":"https://api.github.com/users/kgeographer/gists{/gist_id}","starred_url":"https://api.github.com/users/kgeographer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kgeographer/subscriptions","organizations_url":"https://api.github.com/users/kgeographer/orgs","repos_url":"https://api.github.com/users/kgeographer/repos","events_url":"https://api.github.com/users/kgeographer/events{/privacy}","received_events_url":"https://api.github.com/users/kgeographer/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":12,"created_at":"2018-05-08T18:57:48Z","updated_at":"2018-05-15T14:57:01Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"### An \"edge property\" issue\r\nOver the past few months I have been trying to coordinate development of an update to the _Pelagios Gazetteer Interconnection Format_, calling it **PGIFv2**, on behalf of the [World-Historical Gazetteer](http://whgazetteer.org) project (WHG). [The original PGIF](https://github.com/pelagios/pelagios-cookbook/wiki/Pelagios-Gazetteer-Interconnection-Format) specifies - in RDF format - the required and optional properties of place data contributed to Pelagios for inclusion in its [Peripleo](http://peripleo.pelagios.org) index and search interface. \r\n\r\nWHG is building a very similar index, but needs to account for time in a more granular way than PGIF allows -- hence the move towards PGIFv2. The plan is that Peripleo and WHG will both require contributions in PGIFv2 form, so the same data \"dump\" file of place records from a research group can be ingested by either or both.\r\n\r\nSeparately (i.e. prior to WHG's inception), I have been developing [a temporal extension to GeoJSON, called GeoJSON-T](https://github.com/kgeographer/geojson-t). It proposes an optional \"when\" element added as what the GeoJSON spec calls a \"foreign member\" in a few places within a GeoJSON Feature. \r\n\r\nThe initial idea for PGIFv2 contributions was that they take the form of GeoJSON-T FeatureCollections. These would be valid GeoJSON, and as such readily mappable in web applications and automatically rendered as maps in GitHub.\r\n\r\nBut Linked Open Data is by definition RDF! Ah, no problem, we'll make it GeoJSON-LDT, and it will adhere to the JSON-LD spec! As Rob Sanderson has effectively argued in developing [IIIF](http://iiif.io/api/annex/notes/design_patterns/#design-for-json-ld-first) and [Linked Art](http://linked.art/model/) specifications, JSON-LD is more usable than other RDF syntaxes: aiming to be \"as easy to use as possible without the need for a full RDF development suite.\" As a developer accustomed to parsing JSON data in web applications, I agree!\r\n\r\nBut things have gotten murky from there...\r\n\r\nFirstly, JSON-LD 1.0 does not support ***lists of lists***, so the \"coordinates\" elements of GeoJSON geometries that are more complex than single points (linestrings, polygons, etc.) will not validate as JSON-LD.\r\n\r\nSecondly, the requirement to add temporal attributes of properties introduces the spectre of \"***edge properties***,\" or reification. In PGIFv2 we need to be able to state a valid timespan or period for 1) a place name or geometry; and/or 2) a relation between two places (e.g. \"partOf\"). RDF is essentially triples, but we require quads. As far as I can tell, neither IIIF nor Linked Art make explicit recommendations for meeting that challenge with JSON-LD. I think the event-centeredness of Linked Art obviates the need in that case.\r\n\r\nSo, I backed off the idea of PGIFv2 as GeoJSON-LDT, but I am reminded (again) that LOD is about RDF, so circling back...\r\n\r\n### Toward answers\r\n**_Lists of lists_**. I don't consider this a problem for PGIFv2 unless and until JSON-LD parsers are involved. My understanding is that the W3C Working Group now meeting to develop a JSON-LD updated spec (1.1) will design a workaround. \r\n\r\n**_Edge properties_**. The [JSON-LD spec](https://json-ld.org/spec/latest/json-ld/) recommends Named Graphs (`@graph`) as the way to \"make statements about a graph itself, rather than just a single node.\" The example case is of a graph consisting of multiple statements; in our case `@graph` would almost always consist of a single statement. \r\n\r\nAn example describing partOf relations for Oxford and Abingdon is shown below. Is it too much to ask WHG and Peripleo contributors to organize their data this way, i.e. minting `@graph` IDs? Arguably it isn't tougher than generating PGIFv1 data dumps. The answer probably depends on the size of the contributing project; smaller groups and individuals will struggle to get from CSV to *any* RDF or JSON representation. But that problem extends to things like the (optionally) complex \"when\" element. \r\n\r\nThis suggests a CSV-to-LOD service - subject of a follow-up blog post very soon. The WHG team has come to see this as an essential deliverable for us in any case. \r\n\r\n*Ex 01 - Some partOf relations using `@graph`*\r\n<pre>\r\n{\r\n  \"@context\": \"http://linkedpasts.org/assets/place-v4-context.jsonld\",\r\n  \"related\": [\r\n    { \"@id\": \"http://mygaz.org/graphs/01\",\r\n      \"@graph\": {\"@id\": \"myplace:Abingdon\",\"partOf\": \"myplace:Berkshire\"},\r\n      \"when\": {\r\n        \"timespan\":\r\n          { \"start\": {\r\n              \"label\": \"17c.\",\r\n              \"in\": {\"earliestYear\": \"1600\",\"latestYear\": \"1700\" }},\r\n            \"stop\": {\r\n              \"label\": \"until 1974\",\r\n              \"in\": {\"year\": \"1974\"}}\r\n          }\r\n      }\r\n    },\r\n    { \"@id\": \"http://mygaz.org/graphs/02\",\r\n      \"@graph\": {\"@id\": \"myplace:Abingdon\",\"partOf\": \"myplace:Oxfordshire\"},\r\n      \"when\": {\r\n        \"timespan\":\r\n          { \"start\": {\r\n              \"label\": \"from 1974.\",\r\n              \"in\": {\"year\": \"1974\"}},\r\n            \"stop\": {\r\n              \"label\": \"until present\",\r\n              \"in\": {\"year\": \"2018\"}}\r\n          }\r\n      }\r\n    },\r\n    { \"@id\": \"http://mygaz.org/graphs/03\",\r\n      \"@graph\": {\"@id\": \"myplace:Oxford\",\"partOf\": \"myplace:Oxfordshire\"},\r\n      \"when\": {\r\n        \"timespan\":\r\n          { \"start\": {\r\n              \"label\": \"from 1000\",\r\n              \"in\": {\"year\": \"1000\"}},\r\n            \"stop\": {\r\n              \"label\": \"until present\",\r\n              \"in\": {\"year\": \"2018\"}}\r\n          }\r\n      }\r\n    }\r\n  ]\r\n}\r\n</pre>\r\n\r\n### Furthermore...\r\nThe PGIFv2 format (if made LD-compatible) might also be called the **Linked Places Model**, corresponding to the **Linked Art Model** being developed at Getty, some future **Linked People Model**, and so on...a Linked Pasts suite of models one might say. These models/formats would be used by contributors to the growing number of LOD aggregator projects (like Pelagios and WHG for place, SNAP:DRGN and [SNAC](http://snaccooperative.org/) for people, etc.).\r\n\r\n### Please comment...\r\nThere are alternatives to the Named Graph approach to asserting edge properties in RDF, including \"standard reification\" of rdf:Statements and *n*-ary relations. Are these better? Something else? Please make the case -- the contribution pipeline phase of WHG development can't proceed until a (preferably consensus) decision is taken."},"comment":{"url":"https://api.github.com/repos/LinkedPasts/lp-network/issues/comments/389197937","html_url":"https://github.com/LinkedPasts/lp-network/issues/2#issuecomment-389197937","issue_url":"https://api.github.com/repos/LinkedPasts/lp-network/issues/2","id":389197937,"user":{"login":"kgeographer","id":1753945,"avatar_url":"https://avatars3.githubusercontent.com/u/1753945?v=4","gravatar_id":"","url":"https://api.github.com/users/kgeographer","html_url":"https://github.com/kgeographer","followers_url":"https://api.github.com/users/kgeographer/followers","following_url":"https://api.github.com/users/kgeographer/following{/other_user}","gists_url":"https://api.github.com/users/kgeographer/gists{/gist_id}","starred_url":"https://api.github.com/users/kgeographer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/kgeographer/subscriptions","organizations_url":"https://api.github.com/users/kgeographer/orgs","repos_url":"https://api.github.com/users/kgeographer/repos","events_url":"https://api.github.com/users/kgeographer/events{/privacy}","received_events_url":"https://api.github.com/users/kgeographer/received_events","type":"User","site_admin":false},"created_at":"2018-05-15T14:57:01Z","updated_at":"2018-05-15T14:57:01Z","author_association":"CONTRIBUTOR","body":"The LAWD ontology is here: https://github.com/lawdi/LAWD, and it has _where_, _foundAt_, and _origin_ as predicates with a range of Place. Yes, their Place scope note is a tautology. In CRM land, I think E27_Site corresponds most closely to our working conception, so in a Linked Places ontology (were there to ever be such a thing, I would say lp:Place skos:closeMatch crm:E27_Site.\r\n\r\nI am not beholden to the LAWD ontology; in fact I am deeply skeptical of using a hodgepodge ontologies. It seems to be common practice, but relies on the fact no one will ever actually load this data with all referenced ontologies into a triple store and try to reason with it. The alternative is to create an wholly intact application ontology and use owl:equivalentClass or skos:exactMatch here and there, if you really mean it."}}
{"actor":{"display_login":"kgeographer"}}