On Thu, Dec 5, 2013 at 11:57 AM, Eric Lease Morgan <[log in to unmask]> wrote:

> On Dec 5, 2013, at 11:33 AM, Mark A. Matienzo <[log in to unmask]>
> wrote:
>
> > Wouldn't it make more sense, especially with a system like ArchivesSpace,
> > which provides a backend HTTP API and a public UI, to publish linked data
> > directly instead of adding yet another stopgap?
>
>
> Publishing via a content management system would make more sense, if:
>
>   1. the archivist uses the specific content management system
>   2. the content management system supported the functionality
>
> “There is more than one way to skin a cat.” There are advantages and
> disadvantages to every software solution.
>

I recognized that not everyone uses a collection management system and
instead may author description using EAD or something else directly, but I
think we really need to acknowledge the affordance of that kind of software
here.

I can tell you for certain there are certain aspects of the ArchivesSpace
data model that are not serializable in any good way - or at all - using
EAD or MARC.

Per Corey's message:

I have no objection in principle to using XSLT to provide examples of ways
to do this transformation (I know lots of people have piles of existing
EAD) as long as the resulting data is acknowledged to be less than ideal.
EAD is also not a data model, it's a document model for a finding aid. EAD3
will improve this somewhat, but it's still not a representation of a
conceptual model of archival entities.

My concern about using something like XSLT *specifically* to transform
archival description stored in MARC is that the existing stylesheets assume
that the MARC description is bibliographic description. Archival
description is not bibliographic description.

Mark