Should the canonical identifier resolve to a preferred version?

[mattgarrish]

Without the web publications underpinnings, there isn't as strong a case for recommending URLs for the canonical identifier at the manifest level.

Should we consider removing this recommendation and leaving it to implementations to decide whether URLs are preferred?

[llemeurfr]

In JSON-LD, node identifiers are IRIs (-> URLs per our WG decision), I don't see how we could relax this rule.

It's rather the definition of this identifier that should be relaxed, as every audiobook publication requires an identifier but not all audiobooks will live on the Web (and therefore have an id that can be derefenced).

[mattgarrish]

Right, sorry, I wasn't being terribly clear with this issue. It's not so much URLs I care about as the requirement to dereference to a resource on the web:

The canonical identifier SHOULD be a URL that resolves to the preferred version of the digital publication.

That was fine as long as the basis was "web" publications. Given that we're not dealing with web deployment, it doesn't make a lot of sense to get into what the URL resolves to, if anything.

[llemeurfr]

IMO the main issue with the current specification of a canonical id is this notion of "preferred version of the digital publication".
It's a URL and it's better if it can be dereferenced (this is a basic RDF expectation) but we should stick with what JSON-LD says about this "node identifier" (in JSON-LD speak).
By the way, the term "canonical" may be part of the problem: we have tried to give more emphasis on its use than really needed. ok, "node identifier" is not great and the publication may have other identifiers so "identifier" is not sufficient; "publication identifier" is misleading.

[mattgarrish]

My inclination is that we drop all the prose about preferred versions and just leave it that the canonical id MUST be a URL (which includes URNs) that uniquely identifies the publication. The web resolution is very Web Pub-y, as there isn't a need to have or find a preferred version at the manifest level. Implementations can further expand on the definition to require the URL also resolve to a preferred version, if applicable.

Essentially, it becomes like EPUB's unique-identifier - the preferred identifier among possibly many.

Otherwise, we make resolving conditional so it doesn't bind implementations to web deployment - something like ... if a preferred version exists on the web, it should be the URL used.

@iherman any thoughts on this?

[iherman]

@mattgarrish, that sounds fine to me.