Schema.org Archive/ArchiveComponent extensions in ArchiveGrid

[Bruce Washburn]

Hi all,

At the December 11th meeting I mentioned the prospect of modifying the schema.org JSON-LD that is embedded in ArchiveGrid records to include the Archive and ArchiveComponent types and the holdingArchive relationship.

I've finally implemented that change (for uninteresting reasons it necessitated moving ArchiveGrid to a new platform), and have been testing this change for the past week or so. I think it's ready for some wider evaluation.  If you have a chance, could you take a look and give me advice on how to improve upon this?

All of the 5.4M ArchiveGrid records that are based on MARC records in WorldCat include JSON-LD schema.org data in their HTML source.  

Here's an ArchiveGrid search to return MARC records:

https://researchworks.oclc.org/archivegrid/?p=1&q=type%3Amarc

And here's a URL to view one of those records in the Google Structure Data testing tool, which should detect and display the embedded JSON-LD:

https://search.google.com/structured-data/testing-tool#url=https%3A%2F%2Fresearchworks.oclc.org%2Farchivegrid%2Fcollection%2Fdata%2F950912120

The testing tool throws errors for the (currently) unrecognized Schema.org classes and predicates, as expected.

I have questions about rendering information about the institution that holds the item.  

My previous practice had been to make use of the "offers" relationship and the "offeredBy" structure to link to the associated institution:

"offers": {

  "@type":"Offer",

  "offeredBy": {

    "url":"https://researchworks.oclc.org/archivegrid/archive/123",

    "@type": [

      "Organization",

      "Archive"

     ],

     "name":"American Antiquarian Society"

  }

}

I've retained that structure, and have added a parallel "holdingArchive" relationship:

"holdingArchive": {

  "@type":"Archive",

  "url":"https://researchworks.oclc.org/archivegrid/archive/123",

  "name":"American Antiquarian Society"

}

I noted that ArchivesSpace is now embedding JSON-LD on collection pages (on at least some sites), where the "provider" relationship is used to indicate the responsible institution.

For example, in https://archives.etsu.edu/repositories/2/resources/2:

"provider": {

  "@id": null,

  "url": "https://archives.etsu.edu/repositories/2",

  "@type": "Organization",

  "name": "Archives of Appalachia"

}

So I'm wondering what the best practice is, and whether the parallel rendering I've adopted would be acceptable, at least for now.

Thanks,

Bruce

[Mark A. Matienzo]

Hi Bruce (ccing the public-architypes group), 

This is awesome, and I'm excited to play around with this more; particularly from the standpoint of consuming this data. Could you add this announcement to the pull request for Architypes? <https://github.com/schemaorg/schemaorg/pull/1784>

Per your question about holding information: The structure that the Architypes extension proposes is the use of `holdingArchive`. I will note that there is some discussion on Richard Wallis's unmerged pull request linked above to add the Architypes extension to Schema.org about potential patterns. Steven Folsom from Cornell notes that a potential `holds`/`heldBy` relationship might be useful, and I want to emphasize and acknowledge the distinction between a holding, offering, and ownership. My inclination that your parallel relationships are probably fine but we should document this distinction.

I'm not sure of the origin of the current ArchivesSpace JSON-LD expression but I think Mark Custer at Yale, who is involved in this group wrote the ticket: <https://archivesspace.atlassian.net/browse/AR-1484>. What I infer from the discussion was that the implemented expression doesn't totally converge with Architypes, and that there was at some point a decision to delay further implementation until the Architypes proposal was incorporated into Schema.org.

Cheers,

Mark

--
You received this message because you are subscribed to the Google Groups "Archives and Linked Data Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archives-and-linke...@googlegroups.com.
To post to this group, send email to archives-and...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/archives-and-linked-data/9f66b6fa-7f03-4927-b6cb-8a7de5c745e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Bruce Washburn]

Hi Mark,

I just posted my note to the Architypes pull request, thank you for that suggestion.

Bruce

[Mark Custer]

Hi all,

Just saw this message so chiming in now.  What Mark mentioned above regarding the ArchivesSpace implementation is spot on.  What's available now is just a preliminary (perhaps exploratory) mapping that was done in May - June, 2017.  

Architypes was not available at that point, but I'd like to see the current mappings in ArchivesSpace updated (and expanded to other record types in ASpace) once that extension is available.  For what it's worth, the current mapping followed an example from WorldCat at the time, which is why there is that "library:ArchiveMaterial" type on the each finding-aid landing page.

Here's a link to the current mappings in the source code, which haven't changed since 2017:

• Resource / finding-aid pages: https://github.com/archivesspace/archivesspace/blob/master/public/app/models/resource.rb#L37-L111
• Agent, corporate body pages: https://github.com/archivesspace/archivesspace/blob/master/public/app/models/agent_corporate_entity.rb#L3-L24
• Agent, person pages: https://github.com/archivesspace/archivesspace/blob/master/public/app/models/agent_person.rb#L3-L79
• Agent, family pages: https://github.com/archivesspace/archivesspace/blob/master/public/app/models/agent_family.rb#L3-L24

The reason that we went with "provider" at the time was primarily because "holdingArchive" would not validate. I'd love to see that part of the mapping updated, though, once we're able to use that more precise mapping.

All my best,

Mark Custer