Re: addressable identifier?

>
> On the Web, even in a Semantic Web / RDF context, the idea of canonical
> has just not held up well in most general contexts, in spite of the fact
> that you do see canonical as a value for many link rel attributes.
> Persistence of URL(s) for a Web Publication is critical, but Web resources,
> like people, in spite of our preferences, may be known by more than a
> single, canonical identifier (name).  I would argue we may not want to make
> a single canonical URL a core requirement - though we certainly could
> encourage it as a best practice.
>

If we don't, we'll still need a way to figure out that two URIs are
basically serving the same manifest for a given publication.



> The HTML versus non-HTML manifest URL raised earlier in this thread could
> potentially also be dealt with more as a matter of serialization and
> composition than as a one or the other binary choice.  For a UA wanting
> HTML, the URL pointing to the manifest could result in an HTML
> representation that embeds the manifest, e.g., as a script
> type="application/json" or type="application/ld+json. This representation
> (if the publisher so desired) could then also include/embed  by reference
> the 'primary' resource, so that to a Web browser user it looks like he or
> she has received the content of interest right away.  Machines reading this
> HTML would see the manifest in addition to the primary resource, or could
> just request the manifest only through content negotiation (if the
> publisher wished to offer this option or if we make manifest serialized a
> specific non-HTML way a minimum requirement).
>

This has been discussed on Github previously: content negotiation is by far
the most elegant solution, but we also can't expect that we'll always have
that option available.

For the manifest, there's no clear consensus yet between:

   - external manifest as a JSON representation
   - embedded manifest in a HTML document (probably using script)

It seems that there are more people leaning towards external manifest, but
Florian Rivoal for example has advocated in favour of an embedded manifest
in an HTML document.


As said, we have options here, I would just not want to be overly
> prescriptive when not required.
>

We do have options, but having too many options can always be confusing. We
need to agree at least on how the manifest will be accessed (external or
embedded).

Hadrien