 |
 |
On Thu, Mar 6, 2014 at 11:05 AM, Ethan Gruber <[log in to unmask]> wrote: > 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. For the sake of consumers of this data who might not be deeply acquainted with archives standards but who are interested in building a high-level aggregation of various sets of available resources (like, say, search engines), it would also be nice to see an attempt at a schema.orgrepresentation, too. Perhaps as RDFa or microdata in the regular web UI. Dan, aka "one-trick pony"