Canonicalization algorithm should incorporate `@base`

[iherman]

The current algorithm is based on the "incoming" base value only. However, the author may use the JSON-LD @base term as part of its context, which would then overwrite the value of base. This is not accounted for in the algorithm.

[iherman]

I must admit I am torn on this one.

• On the one hand, @base is a bona fide JSON-LD feature, and all JSON-LD processors are supposed to implement it (and they do)
• On the other hand, we do not talk about those features in the publication manifest, just as we do not talk about a bunch of other features that JSON-LD (even 1.0) has. The current document is such that the manifest can be processed by a dedicated processor without the full power of a JSON-LD one (expecting a full-blown JSON-LD processor for the publication manifest would probably be a big no-no for many implementations)

Cc @BigBlueHat @llemeurfr @rdeltour

[iherman]

(b.t.w., e.g., schema.org is also silent about @base, as far as I know)

[llemeurfr]

expecting a full-blown JSON-LD processor for the publication manifest would probably be a big no-no for many implementations.

I totally agree. Publication manifests are made first for reading applications, which will simply parse the JSON structure and create objects out of them.

Being able to create proper RDF triples from a manifest is the cherry on the cake, as it opens the door to proper SEO for web publications. but for that, the full power of JSON-LD is not necessary.

[llemeurfr]

Re. @base: this will not be usable in packaged publications, but it could be added when the publication is exposed on the Web (as a way to impose an origin to the web publication).

but https://json-ld.org/spec/latest/json-ld/#base-iri is not clear about the use the publishing industry could make of this feature, and really this is a Web Publication question.

[BigBlueHat]

@llemeurfr fwiw, @base can be explicitly set to null in order to force them to be relative URLs.

@iherman whatever we spec here should remain compatible with its upstream foundation (i.e. JSON-LD). If there's additional processing required before it becomes valid JSON-LD, then it needs it's own MIME media type to signal the additional processing requirements. This is especially true now that the rel="publication" discovery mechanism is not used in every case: w3c/wpub#409 (comment)

[BigBlueHat]

Being able to create proper RDF triples from a manifest is the cherry on the cake, as it opens the door to proper SEO for web publications. but for that, the full power of JSON-LD is not necessary.

@llemeurfr fwiw, the Chrome Lighthouse team is adding JSON-LD to their SEO Audits system, so JSON-LD parsing will be the foundation of those tests, and ultimately helping the SEO data be more valid and work as intended by the author of that metadata (a win for everyone).

[iherman]

@BigBlueHat this has come up before:

If there's additional processing required before it becomes valid JSON-LD

that is not the case. We are strictly JSON-LD compliant everywhere (well, that is the intention, if it isn't true somewhere it is a bug).

[BigBlueHat]

@iherman good to know. 😃 I think our past conversations have been around the fact that the "authored" manifest and the "canonical" manifest will result in different data--i.e. they're not equivalent graphs nor would the be equivalent JSON (if the canonicalization result were re-expressed).

I'm not terribly keen on that, but that on its own doesn't justify a separate media type. Changing the way @base works...would.

[iherman]

@BigBlueHat, we should agree once and for all that (a) neither the authored nor the canonical manifests are deviating from JSON-LD and (b) there is no plan to change the way @base work.

You are right that the two manifests are not identical as RDF graphs. I am not overly fond of this either. However, a requirement to the author to systematically express all information in its full JSON-LD complexity (all links expressed as LinkedResource objects, all persons expressed as Person objects, etc.) would represent a too high entry barrier in my view. Hence this approach (I suspect schema.org does something similar, except that they do not formally define the canonicalization.)

(I do not know whether it would have any practical usefulness to add a 'profile' URL-s to the media type to differentiate between authored and canonical manifests; my gut feeling is that nobody would pay attention.)

[iherman]

There is a somewhat larger issue that we should probably mention in the document and may help us to resolve this issue.

The fact is that the Publication Manifest uses only a subset of JSON-LD. Although not formally defined this way, but it is some sort of a profile of JSON-LD. The goal is to define a useful subset that is meaningful for our target community and can be interpreted by a dedicated processor without the need of a full JSON-LD processor. I guess this approach is similar to what Web Annotations, WoT, and possibly Verifiable Claims do. If the author wants to use the manifest to express more complex graphs using the full power of JSON-LD then he/she incurs the dangers that some reading systems would not understand the manifest.

There are number of features of JSON-LD that are not mentioned in the document. Language maps, reverse properties, named graphs, data indexing, explicit blank nodes: these are all JSON-LD 1.0 features that are not referred to, let alone the additional features that JSON-LD 1.1 adds. If we wanted to bring all those features "in", we would end up requiring a full-blown JSON-LD processor in the reading system (which is probably a big no-no, see also an implementer's, i.e., @llemeurfr's reaction in #11 (comment)). What I actually wanted to propose in #11 (comment) is that @base is one of the advanced JSON-LD features that we do not mention and use for publication manifests.

I.e., what I propose:

• We should actually make it clear in the document, in the form of a note, that we use a restricted version of JSON-LD only, i.e., that authors should restrict to the JSON-LD "forms" in this document. They can of course extend with additional JSON-LD features, but they do this on their own peril. I am sure @mattgarrish will find the right terminology for this.
• We should not even mention @base in the document...

(Maybe, when JSON-LD processors will be just as ubiquitous as HTML parsers, we can issue a new version of the Publication Manifest that adds all these rich possibilities, but we are not there. Chrome Lighthouse is only for developers debugging their stuff and not for developing Web Applications with JSON-LD, i.e., the API is not, afaik, part or the browser run-time.)

[mattgarrish]

I'm all for adding an informative section to explain the relationship to json-ld. As it is, without the context of what we're trying to achieve by making authoring simple, we're bound to get questions about why we allow incomplete/invalid json-ld.

[iherman]

@mattgarrish,

"why we allow incomplete/invalid json-ld": we don't. All our metadata are bona-fide JSON-LD. The question we may get is "can I use, say, scoped contexts or JSON literals" (both are JSON-LD 1.1 goodies).