Re: HTML Content Algorithms dont' take external JSON-LD data into account

I don't think this needs to be a current issue for the current WG. However, I do think "extraction" should be explored more fully--likely within the JSON-LD Community Group and probably with the assistance of the RDF.js group and others.

Mainly, I'm not convinced the JSON-LD processing API is the right place to handle extraction (even what's currently there), and feel it would be best (re)modeled as a prerequisite step which passes it's results into a JSON-LD API implementation.

Shifting the bits around that way, we could more fully explore the full range of intermixing of graph data into HTML without encumbering JSON-LD with the processing requirements.

So, while I know the current ship has sailed (my new least favorite phrase...), I think there's opportunity here to build a new (rocket!) ship. ^_^

Rinke, would you be open to documenting and sharing the results of your approach using `describedby`? I'd be happy to explore this alongside you however I can--as I'm sure others would also. Maybe in the CG?

Thanks for starting this thread!
Benjamin


--

http://bigbluehat.com/


http://linkedin.com/in/benjaminyoung


________________________________
From: Ivan Herman <ivan@w3.org>
Sent: Wednesday, April 22, 2020 4:38 PM
To: Gregg Kellogg <gregg@greggkellogg.net>
Cc: Benjamin Young <byoung@bigbluehat.com>; Hoekstra, Rinke (ELS-AMS) <r.hoekstra@elsevier.com>; public-json-ld-wg@w3.org <public-json-ld-wg@w3.org>; Breebaart, Matthijs (ELS-AMS) <m.breebaart@elsevier.com>; Townsend, Andrew S. (ELS) <a.townsend@elsevier.com>
Subject: Re: HTML Content Algorithms dont' take external JSON-LD data into account

Should we add this as an issue, flagged as future work?

Ivan

——
Ivan Herman

(Written on my iPad. Excuses for brevity and misspellings...)

On 22 Apr 2020, at 22:26, Gregg Kellogg <gregg@greggkellogg.net> wrote:


On Apr 21, 2020, at 8:01 AM, Benjamin Young <byoung@bigbluehat.com<mailto: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<mailto: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<mailto:gregg@greggkellogg.net>