no "identifier" element warning

[Jennifer]

We're trying to figure out what this warning that is being thrown by the xml form builder means... 

TYPE	xml_form_builder
DATE	Wednesday, January 28, 2015 - 14:23
USER	jeustis
LOCATION	http://archives.lib.uconn.edu/islandora/object/islandora%3Aroot/manage/overview/ingest?render=overlay&render=overlay&render=overlay
REFERRER	http://archives.lib.uconn.edu/islandora/object/islandora%3Aroot/manage/overview/ingest?render=overlay&render=overlay
MESSAGE	No "identifier" element in the transformed DC into which to set the object ID. Make sure that one is created in the selected transform.
SEVERITY	warning
HOSTNAME	137.99.96.119
OPERATIONS	To be removed

Thanks for any help. PS: We did remove the collection called "To be removed" so linking to it won't work.

Jennifer

[Diego Pino]

Hi Jennifer,

Your form XSLT transform, the one that converts your main metadata datastream(the xml generated by the xml form) to Dublin Core(DC) is not generating/creating a <dc:identifier> element. So islandora does not know where it should put the object PID into DC. Review your xlst transform and make sure that at least one empty dc:identifier element is being added.

-Diego

[Jennifer]

Thanks Diego! 

[Jennifer Eustis]

Actually, I thought about this and we're using a modified LC mods to dc xsl. We modified the date, which was a known issue where Donald provided a solution. We also changed how the subjects were being mapped. However, we didn't change how the identifiers were being mapped. 

It seems strange that this message would suddenly appear, especially since we've been using this modified lc mods to dc for over a year.

Has anyone else seen this error if they are using a modified lc mods to dc xsl? And will just added an empty dc:identifier in this xsl really solve the problem of the warning encountered?

Jennifer

[Diego Pino]

Hi Jennifer, if you got some time post a link to the xslt (or the whole code) and the conflicting mods xml. I'm right now debugging some other xslts so my head is tuned on this and maybe we can find the culprit.

Diego

[Jennifer]

Hi Diego,

Here's what we're working with. It's not very pretty and is a hacked LC mods to dc xsl.

Thanks for the help.

Jennifer

[Diego Pino]

Hi, thanks, if you have one of your MODS XML this could also help. 

[Jennifer]

Here's some samples Diego. Thanks again for the help.

Jennifer

[Ernie Gillis]

Hi Jennifer,

This is actually more a comment for Diego, as he's looking at the XML / XSL.

I didn't think the PID was stored in the MODS record, so to put the PID the DC, it's coming from somewhere else… perhaps?

In files Jennifer provided, the XSL that does the "dc:identifier" for the local identifier values (as opposed to the PID). Her MODS records have a "mods:identifier", but are either a local identifier (like an accession number) or a URL to the finding aid.

The only reference in the XSL for the "dc:identifier" are wrapped in the "mods:identifier", or "mods:location" template match logic…. so I don't see how it would fill with the PID :\

<xsl:template match="mods:identifier">

<dc:identifier>

<xsl:variable name="type" select="translate(@type,'ABCDEFGHIJKLMNOPQRSTUVWXYZ','abcdefghijklmnopqrstuvwxyz')"/>

<xsl:choose>

<!-- 2.0: added identifier type attribute to output, if it is present-->

<xsl:when test="contains(.,':')">

<xsl:value-of select="."/>

</xsl:when>

<xsl:when test="@type">

<xsl:value-of select="$type"/>: <xsl:value-of select="."/>

</xsl:when>

<xsl:when test="contains ('isbn issn uri doi lccn uri', $type)">

<xsl:value-of select="$type"/>: <xsl:value-of select="."/>

</xsl:when>

<xsl:otherwise>

<xsl:value-of select="."/>

</xsl:otherwise>

</xsl:choose>

</dc:identifier>

</xsl:template>

<xsl:template match="mods:location">

<xsl:for-each select="mods:url">

<dc:identifier>

<xsl:value-of select="."/>

</dc:identifier>

</xsl:for-each>

</xsl:template>

[Jennifer]

Hi Ernie,

You're right that the PID isn't stored in the MODS only our handle along with local identifiers such as filenames or accession numbers. This is the xsl from LC. Even though we did some minor changes, this is close to the default in Islandora. We've also been using this xsl for about a year with no warning about the dc:identifier, which only appeared in the last month. 

Jennifer

[Diego Pino]

Hi Jennifer + Ernie, the PID is not stored in MODS, that's true. But i believe it's passed by islandora to the OAI complaint DC

Sadly (sorry) i'm out of my office for a few days and i don't have access to the full islandora code to be able to show you the code where this warning message comes from, but trust me(or not?), DC in Fedora 3.x is fundamental, and the standard behaviour is to add the Object PID to into DC. (just look at your other objects), so islandora is expecting an element where to put the OBJECT PID. There are some online xslt transform apps that can help to debug where the problem is. If you can wait until Friday(the day i will be back) i can debug the XLST.  Maybe you did some updates on your REPO or it's just this MODS. 

-D

[Amanda Lehman]

Hi All,   

I don't know if it's relevant but we started getting a similar error message on batch ingest of images with metadata that was also working fine for months, and started throwing the following last October: 

DOMDocument::loadXML(): Namespace prefix dc on identifier is not       [warning]
defined in Entity, line: 13 FoxmlDocument.php:166
Ingested wyu:117777.                                                        [ok]

However, upon looking at the ingested objects [1] I see the PID and Handle are both in the DC record.  

We recently updated to 7.1.4 with no change in the error message.  

I look forward to seeing what y'all figure out!

Amanda Lehman

Librarian, Digital Collections

University of Wyoming Libraries

[1] http://uwyo.coalliance.org/islandora/object/wyu%3A117777/datastream/DC/view

[Diego Pino]

Hi Jennifer, Ernie and Amanda. I'm back and will give this today a detailed inspection. Amanda: the error you are getting is directly from PHP,  DOMDocument loadXML function and is namespace related (means you are passing an element without namespace prefix or the other way, with prefix but no namespace defined in the xml header, can't remember the exact situation/order right now). Did you made some changes in your MODS to DC xslt? Where/how are you putting the handle inside metadata? Line 13 is  <dc:identifier>http://hdl.handle.net/10176/wyu:117777</dc:identifier>, but after the document was loaded via PHP Domdocument processor and passed to the final FOXML, so i can't be sure how this DC looked before. When you did the Islandora update to head, did you also upgrade Tuque and related modules?

-Diego

[Diego Pino]

Hi Jennifer, your XLST is working OK, DC is correct, but...

I think someone did some partial updates (happens all the time!) in your Islandora/tuque combo and this is causing the problem you are having: islandora_xml_forms in the current implementations does not have title and pid to dc functionality anymore, i remember seeing this when i started working on islandora..but not present anymore at least in xml_forms), so i was a little bit lost searching where this messages came from, took some time and  finally searching in my archives i found it on 7.x-1.2. and until 7.x-14 RC it was still there. Here it is (was) https://github.com/Islandora/islandora_xml_forms/commit/62475b0da1caa3f2ebc25a7605849c6a591aa472#diff-c6aaae392a8d31e06b75759cd16e54b1L236. I did not found any Jira Ticket associated with this change, but assume it was done to fix some bug.

The change/code removal was made by Nigel (Banks). So i assume the transform order(to DC) is different now and title (and/or) PID is set somewhere else. Could not find where,

I would suggest you update to head (7.x-1.4(, including base modules, islandora, tuque and of course XML_forms.

Tell me if you find any partial update on your islandora distro. Hope the helps.

Cheers

-Diego

[Jennifer]

Thanks Diego. I will log this in with the IT ticket I opened. We are planning to update to 7.1.4 in the next month! 

Jennifer