[Archivesspace_Users_Group] daogrp ?

[Steven Majewski]

Thanks, Chris. I’m reimporting everything on a test server, and it seems to be  creating digital objects now. 
I will verify if it is working in all cases when it’s finished a very long import session.    — Steve. 


On May 26, 2014, at 8:37 AM, Chris Fitzpatrick <Chris.Fitzpatrick at lyrasis.org> wrote:

> Hi everyone,
> 
> Just to loop back on this, I just commited a fix for <dao> import on EAD. The issue is that there's a weird bug with Nokogiri SAX parser on jRuby that doesn't send closing tag events for tags that are self-closing or empty. So, something like <dao xlink:title="something" xlink:href="http://blah"></dao> was causing issues, depending on the node that follows the <dao> node. <daoloc> are also supported. 
> 
> <daodesc> supported  are  optional. However, I did notice a slight inconsistency in the spec. <daodesc> can occure in <dao> or <daogrp> or <daoloc>.
> <dao> and <daoloc> can have a @title but not <daogrp>. So, to keep things consistent, I am putting <daodesc> content into a note attached to the digital object. Does this sound reasonable?
> 
> I have updated tickets here:
> 
> https://www.pivotaltracker.com/story/show/71019508
> https://www.pivotaltracker.com/story/show/71836450
> 
> 
> best, chris. 
> 
> 
> 
> 
> Chris Fitzpatrick | Developer, ArchivesSpace
> Skype: chrisfitzpat  | Phone: 918.236.6048
> http://archivesspace.org/
> From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Custer, Mark <mark.custer at yale.edu>
> Sent: Friday, May 09, 2014 6:56 PM
> To: Archivesspace Users Group
> Subject: Re: [Archivesspace_Users_Group] daogrp ?
>  
> Steven,
>  
> When testing this earlier today I stumbled across the fact that you can get DAOs to import as long as they contain a <daodesc> (even though the <daodesc> won’t be imported itself). 
>  
> Example of what will work (right now, at least):
>  
>                    <c04 level="file">
>                        <did>
>                            <container type="Box">48</container>
>                            <unittitle>1 dao outside of the did</unittitle>
>                            <unitdate type="inclusive">undated, 1955</unitdate>
>                        </did>
>                        <dao xlink:title="required-title-2" xlink:href="somewhere" ><daodesc><p>needs a desc, really?</p></daodesc></dao>
>                    </c04>
>  
> I’m sure that doesn’t help much right now, but you could get stuff to import by converting the EAD beforehand, converting each daogrp/daoloc into a dao with a daodesc….  Or something like that.
>  
> Mark
>  
> From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Steven Majewski
> Sent: Tuesday, March 11, 2014 10:47 PM
> To: Archivesspace Users Group
> Subject: [Archivesspace_Users_Group] daogrp ?
>  
>  
> No digital objects were created on importing my EAD. 
>  
> From the import mappings   Data Import and Export Maps  it appears that  <dao>, <daogrp>, <daoloc> & <daodesc> all have assigned mappings,
> but I only see a template for ‘dao’ in ead_converter.rb. 
>  
> We are using <daogrp> in our files, as typically we have links to several page images that make up a letter. 
> ( This will likely change as those images do into our repository and become part of a Fedora object. ) 
>  
> As a test, I’ve tried in one file, removing the <daogrp>’s and turning the <daoloc>’s into <dao>’s, but I get this error:
>  
>  
> Error: Unexpected Object Type in Queue: Expected archival_object got file_version
>  
>  
> Import Mapping for Resources from EAD2002 to ArchivesSpace
>  
>  
>  
>  
>  
>  
>  
> Last Updated:
> 8/31/13
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> DAO's
>  
>  
>  
>  
>  
>  
>  
> <dao>  
>  
> instance.instance_type = digital_object
>  
>   @title
>  
> instance.digital_object.title
>  
>   @role
>  
> instance.digital_object.file_versions[].use_statement
>  
>   @href
>  
> instance.digital_object.file_versions[].uri
>  
>   @actuate
>  
> instance.digital_object.file_versions[].xlink_actuate_attribute
>  
>   @show
>  
> instance.digital_object.file_versions[].xlink_show_attribute
>  
>  
>  
>  
>  
> <daogrp>
> EACH <daoloc> within <daogrp> treated as individual file_versions within a single digital_object instance.
> instance.instance_type = digital_object
> Should these end up being components?
>   @role
>  
> instance.digital_object.file_versions[].use_statement
>  
>   @href
>  
> instance.digital_object.file_versions[].uri
>  
>   @label
>  
> instance.digital_object.file_versions[].title
>  
>   <daodesc>
>  
> instance.digital_object.title
>  
>  
>  
>  
>  
>  
>  
>  
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20140529/6bef0bb8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4943 bytes
Desc: not available
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20140529/6bef0bb8/attachment.bin>