search

periodo / periodo-data

Tracking PeriodO data quality issues
http://perio.do
The Unlicense
5 stars 0 forks source link

CIDOC-CRM mapping #11

Closed rybesh closed 9 years ago

rybesh commented 9 years ago

We need to map the terms we are using in our JSON-LD context to CIDOC-CRM terms, and serve this mapping.

rybesh commented 9 years ago

After some consideration we decided that a formal mapping is not useful. What is needed instead is an answer to the following question: If an organization is using the CRM classes and properties, and they want to use PeriodO URIs to label things, what CRM property should they use to link something to a PeriodO period definition? I see a few possibilities:

  1. They use P2 has type, which implies that PeriodO definitions are instances of E55 Type from the CRM perspective. This seems like the simplest approach, and will work for attaching a PeriodO URI to any instance of E1 CRM Entity.
  2. They take an event-based approach, and assert that some event (e.g. the creation of an object) occurred during (or before, or after, etc.) the period defined in PeriodO. This would imply that PeriodO definitions are instances of E4 Period from the CRM perspective. This would involve creating a lot of extra triples.
  3. I'm sure there are even more possibilities, such as using P158 occupied to link a PeriodO period definition to an E92 Spacetime Volume and then declaring which things have intersecting spacetime volumes… (Note: in CIDOC 6.2 (in progress) P4 Period will directly inherit from from E92 Spacetime Volume, so P158 occupied will no longer be needed

Anyway, AFAIC the "right" choice is the simplest thing that will allow people who are using the CRM classes and properties to use our URIs and successfully filter/search/query/visualize their data the way they want.