Re: tr.rdf doesn't include versionless URLs consistently

On Wed, Nov 22, 2017 at 10:21 AM, Denis Ah-Kang <denis@w3.org> wrote:
>
> Hi Geoffrey,
>
> On 11/21/2017 08:26 PM, Geoffrey Sneddon wrote:
> > Denis—I hope you're the right person to contact about this; if not,
> > please forward it on!
> >
> > For example, we have in tr.rdf:
> >
> > @prefix doc: <http://www.w3.org/2000/10/swap/pim/doc#> .
> > @prefix rec53: <http://www.w3.org/2001/02pd/rec54#> .
> >
> > <https://www.w3.org/TR/2017/WD-webrtc-20170605/>
> >   doc:versionOf <https://www.w3.org/TR/webrtc/>
> > .
> >
> > But we don't have:
> >
> > <http://www.w3.org/TR/2016/CR-css-flexbox-1-20160526/>
> >   doc:versionOf <http://www.w3.org/TR/css-flexbox/>
> > .
>
> Yes, that's true but instead you have
> doc:versionOf <http://www.w3.org/TR/css-flexbox-1/>

Maybe I'm misunderstand all of the moving pieces here, but specref
seems to have no notion of css-flexbox, which then causes problems
with the flexbox tests in WPT (in a versionless directory) not getting
attributed to the CSS WG. Maybe specref's handling for levelled specs
should handle that? (+tobie)

> > Given loading <https://www.w3.org/TR/css-flexbox/> gives the same
> > resource as <http://www.w3.org/TR/2016/CR-css-flexbox-1-20160526/>, I'd
> > have expected it to have appeared in  tr.rdf. (Indeed, I'd expect all
> > current resolvable URLs in /TR/ to appear in tr.rdf. And ideally we'd
> > have some historic archive of all resolvable URLs in /TR/ somewhere.)
>
> These data are extracted at the time of the publication. The `versionOf`
> represents the latest version url in the document.
> Right now, that's how it's done and as you probably know, we introduced
> a couple of links a few weeks ago [1]. The goal is to harmonize these
> links for all the specifications with different levels.
> During TPAC, PLH discussed with a couple of people about what we should
> do with these links and how they should appear in the specs. He started
> showing a mockup to see what people thinks [2].
> You'll notice the mockup display the canonical link without the level.
>
> So in the future, we may add all these links to tr.rdf but for now
> it's still being reviewed.
>
> [1]
> https://github.com/w3c/tr-pages/wiki/Latest-versions-proposal-for-leveled-specifications
> [2] https://www.w3.org/2017/11/versions-proposal.html

I stand by my parenthetical—I'd like to see something with a complete
listing of everything under /TR/, though that would likely have to be
something distinct from tr.rdf (and the various derived JSON files)
given the sheer size of it.

As for why, I'd like to be able to programmatically be able to go from
<http://www.w3.org/TR/2012/WD-css3-ui-20120117/> (which given its age
unsurprisingly doesn't appear anywhere as a node in the graph) to
finding <http://www.w3.org/TR/2015/WD-css-ui-4-20150922/> as the
latest publication of the  CSS Basic User Interface Module. This
obviously, compared with what's in the graph currently, also needs
knowledge that <https://www.w3.org/TR/css-ui-3/> and
<https://www.w3.org/TR/css-ui-4/> are related.

> >
> > Note we also don't have:
> >
> > <http://www.w3.org/TR/2016/CR-css-flexbox-1-20160526/>
> >   rec54:sameWorkAs <https://www.w3.org/TR/2016/CR-css-flexbox-1-20160526/>
> > .
> >
> > And I'd expect that given nowadays it redirects to it (at least if the
> > client sends Upgrade-Insecure-Requests: 1).
>
> True as well. These http->https triples are available only for
> shortlinks (http://www.w3.org/TR/foobar/).
> The reason is when we upgraded /TR with https, the semweb people wanted
> to make sure we don't break the existing URIs so they could follow the
> history of a spec just from the shortlink so to avoid breaking things,
> we added these relations but that use case doesn't apply for dated
> links.
> Although it is true that we could add these triples for dated links,
> it will increase the size of tr.rdf significantly so unless there's a
> good use case, I don't think we should add them.

I guess per my parenthetical it's something to put in a hypothetical
tr-complete.rdf (or even just a tr-archive.rdf, where the complete
graph is the union of that and tr.rdf).

/g

Received on Wednesday, 22 November 2017 16:42:03 UTC