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

Datastream properties #5

Closed

Conversation

Projects
None yet
5 participants
@daniel-dgi
Copy link
Contributor

commented Apr 10, 2015

This opens up a few questions:

  • Namespace prefix for object status and old fedora stuff?
  • Can we nest rdf on Fedora resources? If not, then modified date will have to be re-thought. It's flat right now, which doesn't make a ton of sense.
@awoods

This comment has been minimized.

Copy link
Member

commented Apr 10, 2015

Is there a JIRA ticket associated with this pull-request?

@daniel-dgi

This comment has been minimized.

Copy link
Contributor Author

commented Apr 10, 2015

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";

This comment has been minimized.

Copy link
@mikedurbin

mikedurbin Apr 10, 2015

Contributor

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?

This comment has been minimized.

Copy link
@daniel-dgi

daniel-dgi Apr 10, 2015

Author Contributor

sounds good.

updateTriple(triplesToRemove,
triplesToInsert,
"http://www.loc.gov/premis/rdf/v1#hasEventType",
"migration");

This comment has been minimized.

Copy link
@mikedurbin

mikedurbin Apr 10, 2015

Contributor

I think this belongs on it's own "event" object that includes the event date time. We can easily add these sorts of objects to the repository if we need to capture this information about the migration. It looks like we're saying the nonRdfResource to which we're applying these properties is itself a premis event.

http://id.loc.gov/ontologies/premis.html#hasEventType
http://id.loc.gov/ontologies/premis.html#Event

This comment has been minimized.

Copy link
@daniel-dgi

daniel-dgi Apr 10, 2015

Author Contributor

Pardon my ignorance on this one. How does one create a blank node? Create a NonRDFSourceDescription with no content? Make a container with no children?

This comment has been minimized.

Copy link
@escowles

escowles Apr 10, 2015

Contributor

You post RDF with a blank node in it, e.g.:

<> dcterms:creator [
foaf:name "Bob Smith"
]

@@ -378,6 +378,10 @@ public String getExternalOrRedirectURL() {
}
}

@Override
public boolean isFirstVersion() {
return getVersionId().split("\\.")[1].equals("0");

This comment has been minimized.

Copy link
@mikedurbin

mikedurbin Apr 10, 2015

Contributor

I'm not sure fedora guarantees this naming convention for versions. It may be that it does. In any event, if we don't want to depend on that naming convention, we can determine if a version is the first another way... I'll comment on that below.


String createdDate = v.getCreated();

if (v.isFirstVersion()) {

This comment has been minimized.

Copy link
@mikedurbin

mikedurbin Apr 10, 2015

Contributor

You could provide a boolean "isFirstVersion" to this method that is computed on line 149 with:

version.getObject().getDatastreamVersions(v.getDatastreamInfo().getDatastreamId()).indexOf(v);

This comment has been minimized.

Copy link
@daniel-dgi

daniel-dgi Apr 10, 2015

Author Contributor

right on! i knew i was riding the hack train on that one.

daniel-dgi added some commits Apr 10, 2015

More doc comments. Refactored out property mapping function. Made
functions protected for access that will be required by inevitable
subclasses.
@daniel-dgi

This comment has been minimized.

Copy link
Contributor Author

commented Apr 10, 2015

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.

@awoods

This comment has been minimized.

Copy link
Member

commented Apr 10, 2015

Thanks for the comments, @daniel-dgi.

@daniel-dgi

This comment has been minimized.

Copy link
Contributor Author

commented Apr 13, 2015

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)));

This comment has been minimized.

Copy link
@mikedurbin

mikedurbin Apr 13, 2015

Contributor

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.

updateModifiedDate(triplesToRemove,
triplesToInsert,
createdDate);
}

This comment has been minimized.

Copy link
@mikedurbin

mikedurbin Apr 13, 2015

Contributor

Perhaps we should leave this out for now.

@mikedurbin

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

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.

@ruebot

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

Current date and time would be right, since that would be the last time the object has been modified, right?

@escowles

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

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.

@ruebot

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

That makes sense @escowles.

@mikedurbin

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

That sounds good. In premis, is the "eventType" controlled, or can we put any value there?

@ruebot

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

Yep. A list of them is here; migration.

@mikedurbin

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

That list doesn't include any "modification" or similar event....

@ruebot

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

Oh, is this for the lastModified value? Not the migration?

@escowles

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

@mikedurbin we added an audit ontology for fcrepo4-specific extensions, including contentModification and metadataModification types:

https://github.com/fcrepo4/ontology/blob/master/audit.rdf

@mikedurbin

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

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).

@daniel-dgi

This comment has been minimized.

Copy link
Contributor Author

commented Apr 13, 2015

sure thing

@daniel-dgi

This comment has been minimized.

Copy link
Contributor Author

commented Apr 13, 2015

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.

@escowles

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

@daniel-dgi Yep, that all sounds good to me.

@ruebot

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2015

👍

Date event for migration and lastModified dates. Only setting
datastream properties on last version to save on requests to fcrepo.
@mikedurbin

This comment has been minimized.

Copy link
Contributor

commented Apr 14, 2015

Commits squashed and merged.

@awoods

This comment has been minimized.

Copy link
Member

commented Apr 14, 2015

Resolved with: 445a679

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.