The issue here that I see is that D2RQ will expose the MySQL database
structure as linked data in some sort of indecipherable ontology and the
end result is probably useless. 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.

CIDOC-CRM is capable of representing the structure and relationships
between components of an archival collection. I'm not a huge advocate of
the CRM because I think it has a tendency to be inordinately complex, but
*it* is a standard. Therefore, if the archival community decided that it
would adopt CRM as its RDF data model standard, ArchivesSpace, ICA-AtoM,
EADitor, and other archival management/description systems could adapt to
the needs of the community and offer content in these models.

Ethan


On Thu, Mar 6, 2014 at 10:41 AM, Eric Lease Morgan <[log in to unmask]> wrote:

> On Mar 6, 2014, at 9:47 AM, Mark A. Matienzo <[log in to unmask]>
> wrote:
>
> > ArchivesSpace has a REST backend API, and requests yield a response in
> > JSON. As one option, I'd investigate to publish linked data as JSON-LD.
> > Some degree of mapping would be necessary, but I imagine it would be
> > significantly easier to that instead of using something like D2RQ.
>
>
> If I understand things correctly, using D2RQ to publish database contents
> as linked data is mostly a systems administration task:
>
>   1. download and install D2RQ
>   2. run D2RQ-specific script to read a (ArchiveSpace) database schema and
> create a configuration file
>   3. run D2RQ with the configuration file
>   4. provide access via standard linked data publishing methods
>   5. done
>
> If the field names in the initial database are meaningful, and if the
> database schema is normalized, then D2RQ ought to work pretty well. If many
> archives use ArchiveSpace, then the field names can become “standard” or at
> least “best practices”, and the resulting RDF will be well linked.
>
> I have downloaded and run ArchiveSpace on my desktop computer. It imported
> some of my EAD files pretty well. It created EAC-CPF files from my names.
> Fun. I didn’t see a way to export things as EAD. The whole interface is
> beautiful and functional. In my copious spare time I will see about
> configuring ArchiveSpace to use a MySQL backend (instead of the embedded
> database), and see about putting D2RQ on top. I think this will be easier
> than learning a new API and building an entire linked data publishing
> system. D2RQ may be an viable option with the understanding that no
> solution is perfect.
>
> —
> Eric Morgan
>