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