 |
 |
On Thu, Mar 6, 2014 at 11:05 AM, Ethan Gruber <[log in to unmask]> wrote: > What Mark alludes to here is that the developers of ArchivesSpace could > write scripts, inherent to the platform, that could output linked data that > conforms to existing or emerging standards. This is much simpler than > introducing D2RQ into the application > layer, and allows for greater control of the export models. As a developer > of different, potentially competing, software applications for EAD and > EAC-CPF publication, who is to say that ArchivesSpace database field names > should be "standards" or "best practices?" These are things that should be > determined by the archival community, not a software application. Exactly. I'm also just saying that D2RQ in this case is a bad idea. ArchivesSpace uses an ORM layer, and as such even the database interaction is conveniently abstracted away. ArchivesSpace has an API; leverage the API, not the datastore. Doing the latter in this case is, frankly, a bad idea. Mark