W3C home > Mailing lists > Public > public-publ-wg@w3.org > December 2017

Re: Comments on "Locators for Web Publications"

From: Ivan Herman <ivan@w3.org>
Date: Tue, 12 Dec 2017 13:22:04 +0100
Cc: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>, Tzviya Siegman <tsiegman@wiley.com>, W3C Publishing Working Group <public-publ-wg@w3.org>
Message-Id: <A9E5FA1F-F27A-4102-91AF-56C176D37CE2@w3.org>
To: Baldur Bjarnason <baldur@rebus.foundation>
Hi Baldur,

(More on the technical part)

> On 12 Dec 2017, at 02:34, Baldur Bjarnason <baldur@rebus.foundation> wrote:
> Hi all,

> My suggestions:
> 	• We should postpone further work on PWP fragment identifiers until we know its packaging format and structure.

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 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.)

> 	• 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…


[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

Received on Tuesday, 12 December 2017 12:22:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:52:18 UTC