Migration and Fedora 4 properties
Nick Ruest
Yesterday the Islandora Foundation Fedora 4 interest group met, and much
of our discussion was focused on migration. We were working through
these[1] fcrepo3 Object properties to fcrepo4 and
fcrepo3 Datastream properties to fcrepo4 tables, and we're curious what
other folks have done w/r/t predicates for Fedora 4 properties that are
immutable.
cheers!
-nruest
[1]
https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/migration.md
Benjamin Armintor
--
You received this message because you are subscribed to the Google Groups "Fedora Tech" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech+unsubscribe@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Visit this group at http://groups.google.com/group/fedora-tech.
For more options, visit https://groups.google.com/d/optout.
Nick Ruest
I think the only object property that is left to figure out on our end
is ownerId.
I was thinking dc:creator, but I'm hesitant to use it because I don't
want it to interfere with the descriptive metadata, because we generally
crosswalk our MODS to DC (in the current stack), and were planning on
experimenting with using the MODS to DC element values as object
properties in Fedora 4.
-nruest
On 15-03-31 02:55 PM, Benjamin Armintor wrote:
> Because we're using a fork of fedora-migrate[1], we're migrating things
> according to their practices. In the case of dates, that means using a
> mix of system and application defined RDF properties[2]. Right now I
> don't think they migrate the object properties (label, etc) or RELS-INT,
> but before we go ahead with a large scale migration at Columbia we'll be
> implementing such migrations in our fork[3].
>
> - Ben
>
> 1: https://github.com/projecthydra-labs/fedora-migrate
> 2:
> https://github.com/projecthydra-labs/fedora-migrate/blob/master/lib/fedora_migrate/dates_mover.rb
> 3: https://github.com/cul/fedora-migrate
>
> On Sat, Mar 28, 2015 at 11:20 AM, Nick Ruest <rue...@gmail.com
> <mailto:rue...@gmail.com>> wrote:
>
> Hi folks-
>
> Yesterday the Islandora Foundation Fedora 4 interest group met, and
> much of our discussion was focused on migration. We were working
> through these[1] fcrepo3 Object properties to fcrepo4 and
> fcrepo3 Datastream properties to fcrepo4 tables, and we're curious
> what other folks have done w/r/t predicates for Fedora 4 properties
> that are immutable.
>
> cheers!
>
> -nruest
>
> [1]
>
> --
> You received this message because you are subscribed to the Google
> Groups "Fedora Tech" group.
> To unsubscribe from this group and stop receiving emails from it,
> <mailto:fedora-tech%2Bunsu...@googlegroups.com>.
> Visit this group at http://groups.google.com/__group/fedora-tech
> <http://groups.google.com/group/fedora-tech>.
> For more options, visit https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Fedora Tech" group.
> To unsubscribe from this group and stop receiving emails from it, send
> <mailto:fedora-tech...@googlegroups.com>.
Harry Sidhunata
Currently for ownerID, we use our own custom property ms21:owner.[1]
As for date (created and lastModified), we would like to retain the date information for the migration to from Fedora 3 to 4.
At the moment, we have not decided yet the mapping.
The simplest mapping is to use dcterms:created and dcterms:modfied but reluctant to do so because of similar reason as you stated before for dc:creator.
I would like know as well what mapping other have done especially related to created and lastModified date.
[1] https://wiki.duraspace.org/display/FF/Upgration+Pilot+-+UNSW#UpgrationPilot-UNSW-Fedora3ObjectPropertytoFedora4
Regards,
Harry R. Sidhunata
Technical Support Officer, Library Repository Services, UNSW Library
http://www.library.unsw.edu.au
UNSW Library | UNSW Australia | UNSW Sydney NSW 2052 AUSTRALIA | CRICOS Provider Code: 00098G
Nick Ruest
We've done a bit more work on this, and so far this is what we are
proposing to use:
Object properties
=================
PID -> dcterms:identifier
state -> objState
label -> dcterms:title
createDate -> premis:hasDateCreatedByApplication
lastModified -> premis:hasEventDateTime + hasEventType == migration
ownerId -> premis:hasAgentName + premis:hasAgentNote == migration
Datastream properties
=====================
DSID -> dcterms:identifier
label -> dcterms:title
MIME Type -> mimeType
state -> objState
createDate -> premis:hasDateCreatedByApplication
lastModified -> premis:hasEventDateTime + hasEventType == migration
versionable -> hasVersions
format uri -> premis:formatDesignation
alternate ids -> dcterms:identifier
access url -> dcterms:identifier
checksum -> premis:hasMessageDigestAlgorithm + premis:hasMessageDigest
-----------------------------------------------------------------------
-nruest
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Fedora Tech" group.
> To unsubscribe from this group and stop receiving emails from it, send
Durbin, Michael (md5wz)
We're in the middle of a development effort to create a general purpose migration utility from fedora 3 (and possibly 2) to Fedora 4. While we know we have to make it configurable since individual use cases may vary, we hope to have reasonable default mappings from properties in fedora 3 to fedora 4.
The unfortunate cases are where there's a truly analogous fedora 4 property for the fedora 3 property (like creation date) where we'd love to be able to back-populate that value for old versions, but for various good reasons, fedora 4 doesn't allow manipulation of that property. It means that going forward, in applications built on top of fedora 4, if we want to present those values the same way for versions that were migrated as we do for versions made after the migration, we'll have to build special handling in our applications.
Furthermore, a lack of consensus between the various fedora4 front-end communities as to how to represent these migrated fedora 3 properties will impose further challenges on interoperability.
That said, while we can effectively separate the development of migration tools from the processes of determining these mappings, I hope there's sufficient interest in developing a best-practice mapping before people migrate millions and millions of records.
-Mike
________________________________________
From: fedor...@googlegroups.com [fedor...@googlegroups.com] on behalf of Nick Ruest [rue...@gmail.com]
Sent: Wednesday, April 08, 2015 7:50 AM
To: fedor...@googlegroups.com
Subject: Re: [fedora-tech] Re: Migration and Fedora 4 properties
Hi Harry-
Object properties
=================
PID -> dcterms:identifier
state -> objState
label -> dcterms:title
createDate -> premis:hasDateCreatedByApplication
Datastream properties
=====================
DSID -> dcterms:identifier
label -> dcterms:title
MIME Type -> mimeType
state -> objState
createDate -> premis:hasDateCreatedByApplication
versionable -> hasVersions
-nruest
To unsubscribe from this group and stop receiving emails from it, send an email to fedora-tech...@googlegroups.com.
To post to this group, send email to fedor...@googlegroups.com.
Harry Sidhunata
Nick Ruest
It's been my understanding that dcterms is the proper namespace to use
now. At least that's the way I've always interpreted this[1].
-nruest
[1] http://wiki.dublincore.org/index.php/FAQ/DC_and_DCTERMS_Namespaces
On 15-04-13 01:51 AM, Harry Sidhunata wrote:
> Hi Nick,
>
> Premis seems to me the right choice for owner, created, and modified
> date because it is internally used information and I think I will go
> with that.
> Just curious, could you let me know the reason why you use dcterms
> instead of dc?
>
>
> Regards,
>
> Harry R. Sidhunata
> Technical Support Officer, Library Repository Services, UNSW Library
> Provider Code: 00098G
>