iana:first and iana:last

[VickyPhillips]

Hello All,
We’re currently mapping our Fedora 3.8 METS objects to PCDM and could do with some guidance. I’ve tried accessing the pcdm Google Group in order to post queries there, but I’m not able to access this as I’m getting the following message

This group either doesn't exist, or you don't have permission to access it. If you're sure this group exists, contact the owner of the group and ask them to give you access.

With iana:first and iana:last is it possible to include the elements twice within a pcdm Object to reflect what was the Physical and Logical structural map in METS by using rdf:ID attribute to differentiate between the two? e.g.

<iana:first rdf:ID="PHYSICAL" rdf:resource="http://fcrepo-xxx/fcrepo/rest/ManuscriptTitle/orderProxies/page1Proxy"/>
<iana:first rdf:ID="LOGICAL" rdf:resource="http://fcrepo-xxx/fcrepo/rest/ManuscriptTitle/orderProxiesLogical/page1Proxy"/>

Or do we need to create two Parent PCDM Objects for the Title, one which points to the Physical orderProxies and another (with pcdm:AlternateOrder element included) which points to the Logical orderProxies?

I’m new to all this so any guidance would be very much appreciated.
Thanks,

Vicky Phillips
Digital Standards Manager, National Library of Wales

[escowles]

@VickyPhillips It's generally recommended to have only one iana:first/iana:last per resource so you can keep them matched up. So I would suggest having one resource for the Title with the primary order linked to with iana:first/iana:last, and then putting the other order in a pcdm:AlternateOrder object. If you want to avoid making one order primary and the other secondary, you could put both of the orders in pcdm:AlternateOrder objects.

[VickyPhillips]

@escowles Many thanks for your response. Can I just confirm does the ‘other order’ Object (pcdm:AlternativeOrder) sit alongside the main Title Object (so almost a duplicate Title object, but with possibly different iana:first and iana:last) and different orderProxies Object to reflect the different ordering? Rather than alternativeOrderProxies Object nested underneath the main Title object and alongside the main OrderProxies, as you wouldn’t be able to include the iana:first and last here. If it is similar to a duplicate Title Object I’m hoping that we don’t need to replicate the descriptive metadata e.g. licences across as this would mean duplication of data and as a result more than a single place to update metadata if changes are made. Are there any examples of use of AlternativeOrder available to follow? The only thing I’ve come cross is the following https://www.rootopen.com/git/5cffb8fbb107d71aac4815ad Or institutions you know of who have implemented this.

One other question I have which is regarding storing of FOXML from legacy repository. Is it ok to have this as a Binary (pcdm:hasFile) off the Main Title Object or should it be a Binary on a separate Archived Title Object? Do you know what is best practice in this instance and again are there any examples of this out there, or an institution that has implemented this?

Thanks

[escowles]

There are several options for how to model the AlternativeOrder, but I would generally include it as a child object inside of the main title object, so something like:

# the main object
<> a pcdm:Object ;
     pcdm:hasFile <#file1> ;
     pcdm:hasFile <#file2> ;
     iana:first <#proxy1> ;
     iana:last <#proxy2> ;
     pcdm:hasRelatedObject <#altOrder> .
<#file1> a pcdm:File ;
    rdfs:label "Page 1" .
<#file2> a pcdm:File ;
    rdfs:label "Page 2" .

# the main ordering proxies
<#proxy1> a ore:Proxy ;
    iana:next <#proxy2> ;
    ore:proxyFor <#page1> .
<#proxy2> a ore:Proxy ;
    iana:prev <#proxy1> ;
    ore:proxyFor <#page2> .

# the alternative order and proxies
<#altOrder> a pcdm:AlternativeOrder ;
    iana:first <#alt1> ;
    iana:last <#alt2> .
<#alt1> a ore:Proxy ;
    iana:next <#alt2> ;
    ore:proxyFor <#page2> .
<#alt2> a ore:Proxy ;
    iana:prev <#alt1> ;
    ore:proxyFor <#page1> .

And I think it's fine to have a pcdm:hasFile link from the main object in order to store imported metadata, in FOXML, MARC, or any other format you have. That's what we do in our repository when we migrate objects. In general, I think that wrapping page images and other content files in a page object or FileSet object makes sense, in order to group derivatives and technical metadata with the master files they are derived from. But for metadata files, I don't think that's useful.

[VickyPhillips]

@escowles Many thanks for this. It's all becoming clearer now regarding the Alternative Ordering. Can I just check one thing... I notice that you use pcdm:AlternativeOrder above but looking at the spec it has pcdm:AlternateOrder is it just a typo above?
Thanks also for confirming it's ok to have FOXML as a binary directly off the main object.
Do you have any examples or documentation publicly available on how you've structured things in Fedora and example RDF for an Object. It would be really good for us to see a live example to ensure that we are covering everything. Thanks

[escowles]

@VickyPhillips Sorry for the typo, it is indeed pcdm:AlternateOrder not "alternative".

Unfortunately, we haven't created any public documentation for how we're storing imported metadata files, and we're not currently using Fedora (we developed a Samvera/Valkyrie-based repository that uses a lot of PCDM concepts, but not RDF, to store data).

In terms of Fedora, I think there are two approaches for attaching metadata files:

1. Attach the triples directly to the object, by adding the metadata file to the object container, and including pcdm:hasFile triples in the object's RDF.
2. Creating a child container (e.g., called legacy_metadata or something like that) and using the LDP DirectContainer triples to have it add the pcdm:hasFile triples. This is the way I would recommend, since it makes good use of the API and avoids making updates to the parent object to manage the migrated metadata files.