Re: [archives-and-linked-data] Schema.org Archive/ArchiveComponent extensions in ArchiveGrid

This is indeed awesome Bruce!

Thanks Mark for forwarding to the relevant lists, and again Bruce for
adding to the pull request
<https://github.com/schemaorg/schemaorg/pull/1784#issuecomment-460083032>
comments
on the Schema.org Github.

This will hopefully help push the PR over the edge into the next Schema.org
release, especially with Mark viewing it from the standpoint of potential
data consumption.

Hopefully sometime soon after that merge, Google's testing tool will stop
throwing errors for these terms.

As to the questions raised...

'offeredBy <https://schema.org/offeredBy>', 'provider
<https://schema.org/provider>' & 'holdingArchive' on the surface are
similar, but in detail have significant differences.

   - offeredBy <https://schema.org/offeredBy>
*A pointer to the organization or person making the offer *This Schema
   property is used on the Offer <https://schema.org/Offer> type, which
   describes the an offer to make some Thing available: "*An offer to
   transfer some rights to an item or to provide a service — for example, an
   offer to sell tickets to an event, to rent the DVD of a movie, to stream a
   TV show over the internet, to repair a motorcycle, or to loan a book*."
   It therefore would not be expected to be used as a property for a
   CreativeWork, Collection, etc., but as used by Bruce to relate a thing to
   the organization making it available.

   - provider <https://schema.org/provider> *The service provider, service
   operator, or service performer; the goods producer. Another party (a
   seller) may offer those services or goods on behalf of the provider. A
   provider may also serve as the seller.*
   Despite the Schema leaning towards commercial relationships in its
   descriptions, the provider of a thing is considered to be the producer
   (originator?) of a thing.  As indicated, this does not prevent the provider
   being also being referenced, via offeredBy in an *Offer* (and in our
   case the *holdingArchive* of an *ArchiveComponent)*.

   - *holdingArchive - *
*Archive that holds, keeps or maintains the ArchiveComponent *The specific
   relationship between a Thing (defined as an *ArchiveComponent*) and the
   *Archive* (*Institution with archival holdings. An Archive, or Archives,
   is an organization which keeps and preserves archival material and
   potentially makes it accessible to the public.*) that holds it.

In the examples from ArchiveGrid Bruce has, I believe validly, added a
parallel relationship to that supplied via *Offer*/*offeredBy*, utilising
*holdingArchive*, between the item and the *Archive*.

I would comment that the *Offer* description could benefit from a few extra
properties identifying the parameters of the offer such as
*businessFunction* (Loan - *http://purl.org/goodrelations/v1#LeaseOut
<http://purl.org/goodrelations/v1#LeaseOut>* - practice defined with the
library community), *areaServed*, *availableAtOrFrom*, price (0 - free),
etc.

~Richard.






Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Linkedin: http://www.linkedin.com/in/richardwallis
Twitter: @rjw



On Sat, 2 Feb 2019 at 22:16, Mark A. Matienzo <mark.matienzo@gmail.com>
wrote:

> 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
>
>
> On Fri, Feb 1, 2019 at 4:34 PM Bruce Washburn <washburb@oclc.org> wrote:
>
>> 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
>>
>>
>> --
>> 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-linked-data+unsubscribe@googlegroups.com.
>> To post to this group, send email to
>> archives-and-linked-data@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
>> <https://groups.google.com/d/msgid/archives-and-linked-data/9f66b6fa-7f03-4927-b6cb-8a7de5c745e3%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>