Anyone tried splitting up data imported from dc.date ?

[Karl Goetz]

Hi,

I was asked if its possible to split up dates imported by AtoM from an Archivematica DIP so they could be used to populate the 'start' and 'end' dates as start and end are indexed for searching but 'date' isn't.

We wouldn't be trying to split everything, just dates/ranges which matched certain patterns; for example:

dc.date: c1920

Possibly untouched, or below

start: 1920

end: 1920

dc.date: 1800s - 1950

start: 1800

end: 1950

dc.date: 4-10-1756 - 1-2-1800

start: 4-10-1756

end: 1-2-1800

dc.date: 2-3-1900 through 2000

start: 2-3-1900

end: 2000

You get the idea.

So, anyone tried it?

Thanks,

-- 

Karl Goetz

Mon, Tue, Wed, Technical Services Officer - eResearch

Wed, Thu, Fri Senior Library Officer (Library Systems)

University of Tasmania, Private Bag 25, Hobart 7001

University of Tasmania Electronic Communications Policy (December, 2014).
This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.

[Dan Gillean]

Hi Karl, 

The short answer is: no, I don't believe this is currently possible, and I think it would require significant analysis and some development work to change that. 

I don't work with Archivematica as frequently as my AM colleagues, but I'm pretty sure that right now, all forms of metadata input (whether the metadata.json or metadata.csv files, the templates in AM, or other) either end up as simple Dublin Core, or just in an <mdWrap> element with a type of OTHER in the METS dmdSec. 

During an EAD 2002 XML import into AtoM, the controlled date values are taken from the @normal attribute on the <unitdate> element. DC simple doesn't have equivalent attributes that I'm aware of, and even if it did, we'd still need to alter AtoM's DIP upload code to be able to recognize and parse them. 

I would LOVE to see our integration with Archivematica improved so that more descriptive metadata can be passed - it's one of the challenges of our current maintenance model that we depend on the community to prioritize and sponsor such integrations, even when they seem like they should already exist! 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/A56E6BDB-0845-460E-893D-C28164909410%40utas.edu.au.
For more options, visit https://groups.google.com/d/optout.

[Karl Goetz]

Hi Dan,

In as much as dc.date is supposed to contain (almost) arbitrary date data atom is doing what it should. Our problem is that the atom date field isn’t indexed for search so our options appear to be:

* Configure Elastic to index the text date field

* Populate start_date and end_date from the text date field /where reasonably possible/

* Some combination of the above.

I’m still not sure which is the ‘best’ way, but populating start_date and end_date makes the data integrate better with atom ui - like date range searches - which simply indexing doesn’t provide.

Karl.

To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/CAC1FhZK%3DYNBAVgDAXrW3ox9a9zO%2BSNSNcJOYeCKipaFdZE7zUg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.