Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

when clause in part-of relation #1

Open
gklyne opened this issue Feb 27, 2018 · 7 comments
Open

when clause in part-of relation #1

gklyne opened this issue Feb 27, 2018 · 7 comments

Comments

@gklyne
Copy link

gklyne commented Feb 27, 2018

With reference to place-v3-example.json, line 161 et seq:

  "part_of": [
    { "id": "http://www.mygazetteer.org/place/Greece",
      "when": {"timespans": [["-750","640"]]}
    }

I'm concerned that when interpreted as RDF, this may not mean what it is intended to mean. But first, I'd like to clarify what its is intended to mean ;)

My guess is that it is intended to express that Athens (the containing Feature) was a part of Greece during the period described as ["-750","640"]. (What I think it actually says is something like the place Greece existed for the described period, but this rather depends on the exact way in which when is specified.)

If my initial guess is correct, I'll supply more details here about why I think this is the case, and offer some alternative patterns that could achieve the presumed intent.

Thanks!

@kgeographer
Copy link
Contributor

kgeographer commented Mar 3, 2018

Your guess is correct. By all means what are some alternative patterns? I see the context is not well defined at all, will take another pass at it soon.

@gklyne
Copy link
Author

gklyne commented Mar 8, 2018

A brief example to illustrate the problem I see.

In UK, up to 1974, the town of Abingdon was part of the county of Berkshire, until it became part of Oxfordshire. Oxford, by comparison, was part Oxfordshire since its formation 10th century (I think - my historical knowledge isn't great!). Thus, using the pattern as now, one might write:

{ "id": myplace:Abingdon
  "part_of": [
    { "id": "myplace:Oxfordshire",
      "when": {"timespans": [["1974","2018"]]} ]
    }
}
{ "id": myplace:Oxford
  "part_of": [
    { "id": "myplace:Oxfordshire",
      "when": {"timespans": [["1000","2018"]]} ]
    }
}

Because the subject of when is here is the resource myplace:Oxfordshire rather than the part_of, this could also be written in JSON-LD, equivalently as far as RDF is concerned, as:

{ "id": myplace:Abingdon
  "part_of": [
    { "id": "myplace:Oxfordshire",
      "when": {"timespans": [["1000","2018"]]} ]
    }
}
{ "id": myplace:Oxford
  "part_of": [
    { "id": "myplace:Oxfordshire",
      "when": {"timespans": [["1974","2018"]]} ]
    }
}

Which, using your JSON-LD context, and based on your intended interpretation, would be saying that Oxford was part of OxfordShire between 1974 and 2018 (arguably true, but not very helpful), and that Abingdon was part of Oxfordshire between 1000 and 2018 (not true).

The challenge here is: how to make an RDF statement that qualifies a particular use of part_of?

I've made a few notes about some existing work on the wider issue of what I'm calling "qualified relations", which you can see here:

I'm currently doing some more detailed work with @kintopp on structures to to address the temporality of place relations (like part_of) - I hope we'll have more to say on that soon.

@kgeographer
Copy link
Contributor

Granted the RDF interpretation of this may not be as intended. In any case, the scenario you describe would look like the following in the draft format (length of timespans array should be 5 to allow for earliest/latest start, earliest/latest end, label). Seems to me the subjects of the 'when' for all are their respective 'part_of' elements, but confirming by building a test triple store will have to wait a bit. At least, it's easy for me to imagine code to make that interpretation. When I view this bit in JSON-LD Playground N-Quads it seems to indicate correct s-p-o relations. I will flag this thread in twitter (kgeographer) and seek further input.

{ "type": "FeatureCollection",
  "@context": "http://linkedpasts.org/assets/place-v3-context.jsonld",
  "features": [
    { "@id": "myplace:Abingdon",
       "part_of": [
	        { "id": "myplace:Berkshire",
	          "when": {"timespans": [["1600","1700","","1974",""]]}
	        },
	        { "id": "myplace:Oxfordshire",
	          "when": {"timespans": [["1974","","","2018",""]]}
	        }
      	]
     },
     { "@id": "myplace:Oxford",
       "part_of": [
	        { "id": "myplace:Oxfordshire",
	          "when": {"timespans": [["1000","","","2018",""]]}
	        }
      	]
    }
  ]
}

@gklyne
Copy link
Author

gklyne commented Mar 11, 2018

Hi Karl, thanks for getting back.

Looking at the triples from your JSON-LD playground link:

<myplace:Abingdon> <http://vocab.getty.edu/ontology#broaderPartitive> _:b1 .
<myplace:Abingdon> <http://vocab.getty.edu/ontology#broaderPartitive> _:b3 .
<myplace:Oxford> <http://vocab.getty.edu/ontology#broaderPartitive> _:b5 .
_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.org/geojson/vocab#FeatureCollection> .
_:b0 <https://purl.org/geojson/vocab#features> <myplace:Abingdon> .
_:b0 <https://purl.org/geojson/vocab#features> <myplace:Oxford> .
_:b1 <http://linkedpasts.org/vocab#when> _:b2 .
_:b2 <http://linkedpasts.org/vocab#timespans> "" .
_:b2 <http://linkedpasts.org/vocab#timespans> "1600" .
_:b2 <http://linkedpasts.org/vocab#timespans> "1700" .
_:b2 <http://linkedpasts.org/vocab#timespans> "1974" .
_:b3 <http://linkedpasts.org/vocab#when> _:b4 .
_:b4 <http://linkedpasts.org/vocab#timespans> "" .
_:b4 <http://linkedpasts.org/vocab#timespans> "1974" .
_:b4 <http://linkedpasts.org/vocab#timespans> "2018" .
_:b5 <http://linkedpasts.org/vocab#when> _:b6 .
_:b6 <http://linkedpasts.org/vocab#timespans> "" .
_:b6 <http://linkedpasts.org/vocab#timespans> "1000" .
_:b6 <http://linkedpasts.org/vocab#timespans> "2018" .

Here, note that the subjects of the when triples are the blank nodes referenced by the part_of (broaderPartitive), not the part_of relation itself.

It looks to me as if the "id:": "@id" in your JSON-LD context isn't being recognized for Oxfordshire and Berkshire. If that were happening, I think the blank node _:b1 should be <myplace:Berkshire>, and _:b3 and _:b5 should both be <myplace:Oxfordshire>. Then the triples look like this:

_:b0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <https://purl.org/geojson/vocab#FeatureCollection> .
_:b0 <https://purl.org/geojson/vocab#features> <myplace:Abingdon> .
_:b0 <https://purl.org/geojson/vocab#features> <myplace:Oxford> .

<myplace:Abingdon> 
    <http://vocab.getty.edu/ontology#broaderPartitive>
        <myplace:Berkshire> .
<myplace:Abingdon>
    <http://vocab.getty.edu/ontology#broaderPartitive>
        <myplace:Oxfordshire> .
<myplace:Oxford> 
    <http://vocab.getty.edu/ontology#broaderPartitive> 
        <myplace:Oxfordshire> .

<myplace:Berkshire> <http://linkedpasts.org/vocab#when> _:b2 .
_:b2 <http://linkedpasts.org/vocab#timespans> "" .
_:b2 <http://linkedpasts.org/vocab#timespans> "1600" .
_:b2 <http://linkedpasts.org/vocab#timespans> "1700" .
_:b2 <http://linkedpasts.org/vocab#timespans> "1974" .

<myplace:Oxfordshire> <http://linkedpasts.org/vocab#when> _:b4 .
<myplace:Oxfordshire> <http://linkedpasts.org/vocab#when> _:b6 .

_:b4 <http://linkedpasts.org/vocab#timespans> "" .
_:b4 <http://linkedpasts.org/vocab#timespans> "1974" .
_:b4 <http://linkedpasts.org/vocab#timespans> "2018" .

_:b6 <http://linkedpasts.org/vocab#timespans> "" .
_:b6 <http://linkedpasts.org/vocab#timespans> "1000" .
_:b6 <http://linkedpasts.org/vocab#timespans> "2018" .

Here, the different timespans are clearly asscociated with the same Oxfordshire, not different entities corresponding to the different part_of statements.


There's another issue here: the "http://linkedpasts.org/vocab#timespans" properties are not ordered and hence can't be distinguished according to their roles in the timespan description. It works fine as long as you are just using JSON, as the order is preserved anyway, but when you map to RDF that ordering is lost. I suggest that:

"timespans": { "@container": "@set",  "@id": "lp:timespans" }

in your JSON-LD context should be:

"timespans": { "@container": "@list",  "@id": "lp:timespans" }

(The @list results in the generated RDF using a list structure (cf http://www.w3.org/TR/rdf-schema/#ch_collectionvocab) rather than simple properties.)

@kgeographer
Copy link
Contributor

It works fine as long as you are just using JSON

This all began as GeoJSON-T, the 'LD' a recent add: my excuse for a (so far) rushed/lazy take at this. Your patience is appreciated.

It looks like the challenge of assigning attributes (valid time a.k.a. 'when') to relations remains. I assumed JSON-LD would make this simpler than RDF/XML etc - dunno why, since it's the same underlying model.

Using @graph gets us closer, though the semantics of timespans are absent as a list.

{
  "@context": "http://linkedpasts.org/assets/place-v3-context.jsonld",
  "related": [
    { "@id": "http://linkedpasts.org/graphs/01",
      "when": {"timespans": [["1600","1700","","1974","from 17c. until 1974"]]},
      "@graph": {"@id": "myplace:Abingdon","part_of": "myplace:Berkshire"}
    },
    { "@id": "http://linkedpasts.org/graphs/02",
      "when": {"timespans": [["1974","","","2018",""]]},
      "@graph": {"@id": "myplace:Abingdon","part_of": "myplace:Oxfordshire"}
    },    
    { "@id": "http://linkedpasts.org/graphs/03",
      "when": {"timespans": [["1974","","","2018",""]]},
      "@graph": {"@id": "myplace:Oxford","part_of": "myplace:Oxfordshire"}
    }
  ]
}

I added the semantics of timespans from PeriodO to the @context, which looks like the following, and produces quads that seem okay. I suppose a thing to do next is generate a good sized example and try to do some SPARQL queries on them. I have not yet committed to making a triple/quad store for World-Historical Gazetteer, but all this seem to be a means to that end, so inevitable.

{
  "@context": "http://linkedpasts.org/assets/place-v4-context.jsonld",
  "related": [
    { "@id": "http://linkedpasts.org/graphs/01",
      "@graph": {"@id": "myplace:Abingdon","part_of": "myplace:Berkshire"},
      "when": {
        "timespan":
          { "start": {
              "label": "17c.",
              "in": {"earliestYear": "1600","latestYear": "1700" }},
            "stop": {
              "label": "until 1974",
              "in": {"year": "1974"}}
          }
      }
    },
    { "@id": "http://linkedpasts.org/graphs/02",
      "@graph": {"@id": "myplace:Abingdon","part_of": "myplace:Oxfordshire"},
      "when": {
        "timespan":
          { "start": {
              "label": "from 1974.",
              "in": {"year": "1974"}},
            "stop": {
              "label": "until present",
              "in": {"year": "2018"}}
          }
      }
    },
    { "@id": "http://linkedpasts.org/graphs/03",
      "@graph": {"@id": "myplace:Oxford","part_of": "myplace:Oxfordshire"},
      "when": {
        "timespan":
          { "start": {
              "label": "from 1000",
              "in": {"year": "1000"}},
            "stop": {
              "label": "until present",
              "in": {"year": "2018"}}
          }
      }
    }
  ]
}

@gklyne
Copy link
Author

gklyne commented Mar 12, 2018

  1. Concerning time-qualified part_of: I think there may be easier ways than using @graph: I'll get back to you on that. I think the @graph approach is roughly equivalent to the "Named graphs" approach in my Qualified properties notes. You might be interested to look at the "Specialized object resources" pattern there, which is quite close to the triples from your original approach.

  2. Concerning timespans. For use with linked data, I'd recommend rather than:

     ["1974","","","2018",""]
    

to use a new node with named properties, thus:

    {
        "earliestStart": "1974",
        "latestStart": "",
        "earliestEnd": "",
        "latestEnd": "2018",
        "label": ""
    }

The unknown/unspecified values could be elided, and the resulting timespan assigned an identifier if required, thus:

    {  "id": "mytimespan:Abingdon_in_Oxfordshire",
        "earliestStart": "1974",
        "latestEnd": "2018"
    }

This approach would generate simpler linked data structures than the list approach, and I think it could be combined more smoothly with the PeriodO references and semantics. Your later examples in your last post are very similar, and may be easier to adapt to various usages. The following possible usage pattern occurred to me:

    "timespan":
      { "label": "Period since 1794 reorganization of Oxfordhsire/Berkshire county boundaries",
        "start": {
          "label": "from 1974.",
          "in": {"year": "1974"}
        },
        "stop": {
          "label": "until present",
          "in": {"year": "2018"}
        }
      }

(This is just a part of your example, with the addition of a label for the period overall as well as the start and end times.)

@gklyne
Copy link
Author

gklyne commented Mar 30, 2018

Apropos nothing in particular, but maybe related to above discussion of timespan representations, I just noticed this on W3C SWIG mailing list:

It talks about problems with JSON-LD and GeoJSON - I thought it might be worth flagging up.

(Concerning the main discussion about proposals for representing temporally constrained relations, I've not forgotten - I hope I'll have some more pointers for you soon.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants