Re: Comments on "Locators for Web Publications"

Baldur there's some interesting stuff hiding in this email. :) Could you post these as issues on publ-loc's GitHub repo?

https://github.com/w3c/publ-loc/issues


<https://github.com/w3c/publ-loc/issues>

The actionable points in here do need some action. :)


Thanks, Baldur!

Benjamin

--

http://bigbluehat.com/

http://linkedin.com/in/benjaminyoung

________________________________
From: Baldur Bjarnason <baldur@rebus.foundation>
Sent: Tuesday, December 12, 2017 1:15:20 PM
To: Ivan Herman
Cc: Hadrien Gardeur; Daniel Glazman; Tzviya Siegman; W3C Publishing Working Group
Subject: Re: Comments on "Locators for Web Publications"



Hi Ivan,

> On 12 Dec 2017, at 07:22, Ivan Herman <ivan@w3.org> wrote:
>
> The definition of a fragment identifier is only a (very) small part of the current document[1]. The definition itself does _not_ depend on the packaging format, and concentrates only on the case when there is a URI for a collection of document (which, as we agreed, is the essence of a WP, regardless of its packaging details). There is actually an open issue[2] on whether we need a fragment identifier in the first place. We can obviously add, if we think it is necessary, additional fragment id-s to a specific packaging at some point later, but I completely agree that this should be done only when we have more knowledge about the packaging format.

We don’t know yet what the packaging format offers in terms of URLs, locators, identifiers, or interoperability with how those are handled on the web itself.  That question will only be answered once we know what it/they support in terms of storing HTTP requests and responses and how those are exposed to package consumers. We don’t know whether the packaging format or JSON manifest format give us affordances to simplify the fragment identifier structure in order to increase ease of use in content production (which is vital, the current proposal is much to verbose to be usable by content producers). And I also disagree with basing the fragment identifier on the annotation data model.

So IMO it’s much to early to continue serious work on a PWP fragment identifier. Minting a half-baked one first and then a proper one later that’s better aligned with the format is just going to waste resources and cause confusion. Maybe a general purpose fragment identifier—independent of the packaging format—_is_ the best solution, but we won’t actually know that until we have the packaging formats (or more concrete proposals) in front of us. We can’t even properly answer the question yet as to whether it’s necessary to create a fragment identifier for PWPs until we have more concrete details on PWPs.

>
>>
>>       • We should build a compelling case, including use cases, case studies, testimonials from companies, etc. for the WHATWG to support the proposal that fragment identifiers for arbitrary ranges in an HTML resource is a vital addition to the web if it is to accommodate publications.
>
> Yes, if we concentrate on one specific HTML resource, it would be good to have something like that. And there is no disagreement on the fact that this work should not be done in this WG; it is not even part of the discussion. Whether this should be done in the WHATWG or the Web Platform WG is an issue that is also not for us to decide.
>
> What we _do_ have, but only in the sense of having it inherited from the Web Annotation spec, are Selectors defined by that spec that do define ranges in an HTML resource in terms of JSON(-LD) properties.
>
> (Personally, I have my doubts whether this Working Group is in position to do that type of lobbying and initial implementations to get it through the WHATWG/WPWG. But that is another story.)

If we can’t get through to them, then it can’t be done. They are the platform. Without browser buy-in, then at best what we can do is add ancillary features for specialised UAs. Building up resources, tactics, and strategies for organised lobbying of the WHATWG is essential, long term, for the various publishing industries if they want their needs to be accommodated in the browser space. Informal discussions are unlikely to work. (I know this an opinion many in the WG disagree with and many who might even agree in principle consider it impossible. It’s still the right thing to do.)

Building a fragment identifier for Web Publications whose primary goal is to enhance linking to HTML resources is IMO absolutely entering the territory of the WHATWG. An annotations data model is one thing, once you turn that into a fragment identifier you are relying on technicalities to protect you from accusations of overreach and conflict.

>
>>
>>       • We should concentrate on providing an extremely small set of general purpose JSON-LD properties so that our work on locators isn’t limited to just Web Annotations but can be reused in other formats such as schema.org or Activity Streams.
>
> This is exactly what the Locator document does (modulo possible name change). It defines three different Selectors, that are JSON objects with some properties. And it also defines the Positions that ensure a different structure, also in terms of JSON objects with some properties. They may not be the right ones, that is of course a matter of discussion. There is also an open issue on whether the 'Position' structure is necessary or not[3]; we may decide to drop that part an concentrate on a few (namely three) extra selectors only.
>
> (Our document does not refer to JSON-LD but only JSON. The annotation spec is, in fact, JSON-LD, and the JSON we added follow the same structures, ie, it could also be considered JSON-LD. However, if we want to take that aspect seriously, we would also have to extend the formal RDFS Vocabulary for annotations[4]. This can be done, maybe should be done, but only later.)
>
> Bottom line: I am not sure whether, and if yes where, we really disagree…

We have a fundamental disagreement in that I disagree with the notion that spanning or including multiple resources in a single link structure is a good idea. Multiple resource targets requiring multiple links is how the web is structured currently. It creates too much of a conceptual mismatch with existing parts of the web stack. _Especially, in a fragment identifier._

I also disagree with us extending or iterating on web annotations. If those specifications require more work then that should be done by those who are actually running annotation services in production and based on their needs. My suggestion was to create a small set (like, one or two) of properties that are general purpose JSON-LD properties for indicating membership in a web publication, not to extend the annotations data model. That might even be as simple as giving the rel values we mint alternate full URLs to make it easier to integrate them into JSON-LD contexts. And that’s mostly to make adding publication-specific support to other formats more convenient—not a hard requirement by any means. Activity Streams, for example, support link objects with rel values. It’s a bit verbose but definitely doable without any extensions. Adding affordances for JSON-LD contexts would be a nice-to-have that we could work on at a later date once the foundation is ready (or it could be a side effect of the manifest work if that ends up in JSON-LD).

I disagree with the notion that we are in any way ready to even know whether a fragment identifier for PWPs is needed, let alone what it should look like. Further work on that should be postponed.

And finally, I think fragment identifiers for (non-portable) Web Publications exist only to bypass other standards organisations and working groups. That is a pretty substantial disagreement that I don’t see us resolving any time soon.

By all means, people should use the web annotations data model. I just don’t think we’re the right venue to extend it, and if we do, we are likely to get it wrong unless we get annotation service vendors involved in a serious way. And we definitely shouldn’t turn it into a fragment identifier.

So, we actually disagree quite substantively, from what I can see.

- best
- Baldur Bjarnason
  baldur@rebus.foundation

>
> Ivan
>
>
> [1] https://w3c.github.io/publ-loc/#ErsFragmentId_def
> [2] https://github.com/w3c/publ-loc/issues/6
> [3] https://github.com/w3c/publ-loc/issues/29
> [4] https://www.w3.org/TR/annotation-vocab/
>
>
>
> ----
> Ivan Herman, W3C
> Publishing@W3C Technical Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>