Change / versioning policy about periodo-data HOT 6 CLOSED

First draft at https://github.com/periodo/periodo.github.io/blob/source/change-policy.md

from periodo-data.

Jan 25 comments from @atomrab:

1. Notes. This policy treats notes as direct quotes from the source. I, and the students I've had working on this, have used them a little more loosely, either as a place to put information from the source that has been parsed or shifted around because there wasn't a good place for it (e.g. http://n2t.net/ark:/99152/p0fp7wv8644, where after discussion with Lex I dropped in some additional fields in his spreadsheet), or as a place to expand on the source context that provided label and date information (e.g. http://n2t.net/ark:/99152/p02q72z6c67, where the student quoted the text bits that he used for the labels -- but embedded selections in his own wording). We might want to insist that these can't be changed after the patch is merged, and that any further modifications or comments should be take place in the editorial notes field, but it might be confusing to treat them as transcriptions (that is, the data-entry person might have made a mistake in his OWN wording that he'd like to fix, and I would assume we're ok with this).

2. Date-time descriptions of temporal intervals. I do think that we need to preserve some flexibility here, especially if we find new and interesting ways to represent uncertainty (e.g. "circa"). But if we say that these can change at any time, will this spook collaborators like ARIADNE, who are already using our ISO dates to sort their material, or future collaborators who are worried about having to change their SPARQL queries or API calls?

from periodo-data.

@atomrab, here are the changes I made in response to your comments:
periodo/periodo-website@42ea479...d9f528a

And here's the latest version:
https://github.com/periodo/periodo.github.io/blob/source/change-policy.md

If you're OK with this version I will add a link to it from the technical overview.

from periodo-data.

@atomrab Are you OK with the latest draft of this? If so I will link from the website and close this issue.

from periodo-data.

@rybesh sorry, I let the ball drop here while dealing with the mounting insanity of this semester. Generally, this looks good, but I have two comments:

1. I'm worried about the requirement that there be a dcterms:spatial item. We don't always provide these, as far as I can tell, and it will get harder and harder as we go back in time, at least until we can connect to historical gazetteers. I think it's reasonable to insist that every record must have EITHER a spatialCoverageDescription OR a spatialCoverage. We have to deal with records that lack the former, because we have situations like the BM vocabulary where they don't say "Japan" but it can be inferred with certainty, but we also have to deal with records that -- for the moment -- lack the latter, since "Prussia" isn't "Germany" (see e.g. http://n2t.net/ark:/99152/p06c6g3fx98). Since we don't want people to generate records that have neither, I think we should specify that one or the other must be there (and that description can never be changed, but spatial can be changed any time).

2. I would like to make it possible to expand changes to skos:note to include "the addition of further clarifications derived from the source". It's not always just a matter of clerical errors here, unless those include "forgot to provide some clearly relevant information from the source", which has come up in some of my student submissions. We could provide this in the editorial notes, but I think this doesn't preserve the separation between source and editor that the model tries to maintain.

The language on changing the expression of dates is great, and should calm any concerns on the part of those using the platform.

from periodo-data.

I'm worried about the requirement that there be a dcterms:spatial item. We don't always provide these, as far as I can tell, and it will get harder and harder as we go back in time, at least until we can connect to historical gazetteers.

Even when we can connect to historical gazetteers, there will always be cases where there is not an existing gazetteer entity that suits the spatial coverage description. I think we should insist that at least one be provided, even if it is just smallest modern spatial entity that fully contains the (imagined) region corresponding to the spatial coverage description or inferred from the source. (This would still require us adding some broader entities such as continents.)

I would like to make it possible to expand changes to skos:note…

How's this? periodo/periodo-website@6102c58

from periodo-data.