 |
 |
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