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

On Wed, Nov 22, 2017, at 17:41, Geoffrey Sneddon wrote:
> 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)

I'd love to get level specs handled properly, but for that to happen
there would need to be actual agreement across W3C WGs as how to do
leveled specs. I've been pushing for consistency here for years at this
point. Unsuccessfully.

Alternatively, I'd need to decide on one way to handle levels and
rewrite a bunch of stuff in Specref to support that. That would require
a company to step up and support the work, however.

In the meantime, fixing your issue is trivial:
https://github.com/tobie/specref/pull/422
 
> > > 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.

This is pretty much what Specref gives you, btw. I has most of the
historics.
 
> 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.

So that's what the reverse lookup API gives you:

https://api.specref.org/reverse-lookup?urls=http://www.w3.org/TR/2012/WD-css3-ui-20120117/

The versions field's first item actually contains css-ui-3-20170302,
which when fed back into the API:

https://api.specref.org/bibrefs?refs=css-ui-3-20170302

Which references https://www.w3.org/TR/2017/CR-css-ui-3-20170302/.

Close, but not quite there.

Again, fixing levels here would do wonders.

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

Yup.

> > > 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/>

Specref handles everything as https. So:

https://api.specref.org/reverse-lookup?urls=https://www.w3.org/TR/2012/WD-css3-ui-20120117/

and

https://api.specref.org/reverse-lookup?urls=http://www.w3.org/TR/2012/WD-css3-ui-20120117/

always point to the same resource.

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

Overall, it seems solving levels in Specref would give you all of what
you need. It's imho a much needed improvement, but it's a large and
non-trivial refactoring.

Happy to discuss it further offline.

--tobie

Received on Wednesday, 22 November 2017 22:24:24 UTC