Datastream properties #5
Conversation
variable in sparql queries to prevent duplicates. Doc comments.
|
Is there a JIRA ticket associated with this pull-request? |
|
https://jira.duraspace.org/browse/FCREPO-1437 Sorry, put PR in Jira ticket, but not Jira ticket in PR. |
|
|
||
| // Map dates and object state | ||
| if (pred.equals("info:fedora/fedora-system:def/model#createdDate")) { | ||
| pred = "http://www.loc.gov/premis/rdf/v1#hasDateCreatedByApplication"; |
There was a problem hiding this comment.
Since we'll likely ultimately make these configurable, should we perhaps take the first step now and have our mapping encapsulated in a data structure or single method?
functions protected for access that will be required by inevitable subclasses.
|
This still needs work on the blank nodes. The code's been changed so it looks like the comment is outdated but the work still needs to be done. Don't merge yet. |
|
Thanks for the comments, @daniel-dgi. |
|
Ok, it's ready for review and test now. All previous feedback has been addressed. |
| NodeFactory.createLiteral("migration"))); | ||
| triplesToInsert.addTriple(new Triple(bnode, | ||
| NodeFactory.createURI(eventDatePred), | ||
| NodeFactory.createLiteral(object, XSDDatatype.XSDdateTime))); |
There was a problem hiding this comment.
It looks like the hasEventDateTime is the date of the "migration" event, not the date that the migrated version was updated.
http://id.loc.gov/ontologies/premis.html#hasEventDateTime
That said, it's not clear to me how, or whether to capture the last modification date for datastreams.
|
OK... so I think using a premis event in that way to represent modification date is incorrect, but I don't have a suggestion for what is right. Maybe we should use a premis event for the migration action associated with either the whole object migration or each version migration, but give it the current date, not the date of the action and use something else (perhaps the old fedora3 URI) as our placeholder for the lastModifiedDate for each datastream. I think that's slightly better because if we misuse the date for the premis migration event, application code may wrongly assume something about our resources, whereas if we use the undocumented fedora3 lastModifiedDate uri, application code won't assume (or know) anything. |
|
Current date and time would be right, since that would be the last time the object has been modified, right? |
|
IMHO, it would be fine to create a migration event with the current timestamp, and a modification event with the datastream's lastModified timestamp. It seems like using the current timestamp for the modification event would imply that you'd changed it, not just migrated it. |
|
That makes sense @escowles. |
|
That sounds good. In premis, is the "eventType" controlled, or can we put any value there? |
|
Yep. A list of them is here; migration. |
|
That list doesn't include any "modification" or similar event.... |
|
Oh, is this for the lastModified value? Not the migration? |
|
@mikedurbin we added an audit ontology for fcrepo4-specific extensions, including contentModification and metadataModification types: https://github.com/fcrepo4/ontology/blob/master/audit.rdf |
|
How convenient! Alright, @daniel-dgi , if you could update this PR to use esme's modification even type for the premis event representing datastream or object modification date. You may include an additional "migration" premis event type for the whole object modificaiton if you'd like which should include the evenDate with the current timestamp (ie, the time you run the migration code). You can use your discretion about whether you want to create and include modification dates when fedora 3 doesn't have them (ie, the commented code above where the created date is used). |
|
sure thing |
|
I assume i'll be using http://fedora.info/definitions/v4/audit#contentModification for datastream modification and http://fedora.info/definitions/v4/audit#metadataModification for object modified date? Also, I guess this highlights that these event types are URIs. I have them coded in as literals. I'll change that too. |
|
@daniel-dgi Yep, that all sounds good to me. |
|
👍 |
datastream properties on last version to save on requests to fcrepo.
|
Commits squashed and merged. |
|
Resolved with: 445a679 |
LIBAVALON-166. Initial implementation of adding "bibRef" note
This opens up a few questions: