> On Apr 21, 2020, at 8:01 AM, Benjamin Young <byoung@bigbluehat.com> wrote: > In the meantime, JSON-LD already recommends the use of an HTTP Link header using `rel="alternate"` for discovering JSON-LD variant for the current resource request. So, the same system can be applied to a link element with the same conceptual result: `<link rel="alternate" type="application/ld+json" href="..." />` Conceptually, this may be true, but the processing model doesn’t cause a JSON-LD processor to look for such link relationships within a document, only in HTTP headers. As it is now, there is no good way to handle your specific use case. Something like an @import keyword, contained within a document, might do what you want, or if @included were to take an IRI value to cause it to dereference. That’s something the group might take on after the recommendation is complete. However, in other sectors, there is pushback on having a format which requires any dereference at all (including context files), so these needs must be balanced. > On Apr 21, 2020, at 8:52 AM, Hoekstra, Rinke (ELS-AMS) <r.hoekstra@elsevier.com> wrote: > Looking at the link types, I think the POWDER "describedby" seems the most apt (though "item" comes close). It would be great to have something close to the "imports" that JSON-LD uses for the contexts, *and* to have some kind of recommendation in the spec on linking out to external JSON-LD sources from HTML. We did consider “describedby”, but there is a subtle difference. DescribedBy would be appropriate for describing the content of an HTML page (i.e., this is an HTML page about Berlin), whereas an “alternate” link relationship would provide an alternate representation for what the HTML page, itself, describes. The difference between the a description of a WikiPedia page on Berlin, and a description of Berlin itself. But, in any case, that ship has sailed. Gregg Kellogg gregg@greggkellogg.net
Received on Wednesday, 22 April 2020 20:25:25 UTC