Re: Feedback sought on reorganizing the list of W3C Technical Reports

The concept of 'families' sounds great to me. Two immediate comments:

- It would be great if a 'family' had its own stable W3C URI (with some reasonable resource returned when dereferencing it) and would not only appear as a structure within the web site. I always had problems when, in a references, a presentation, etc, people were asking me to give a reference to, say, RDF. Some of the groups published an 'overview' document on TR, others maintained a wiki page or a page on date space, etc; I think it would greatly help if a family was a real and systematic resource.

- I am not sure if we will be able to retain a strict hierarchy, ie, that a specific TR would belong to a single family. (I am not sure that was your intention, but that is how the table seems to be structured). There are overlaps: just from my own practice we have the DPUB-ARIA work that is as much a publishing document as an ARIA one, we have overlaps between web annotations and some publishing work again, etc. There may be a "primary" family, mostly due to the WG that develops it, but there should be links to other families, too.

Thanks!

Ivan

P.S. I presume the details of the tables are not really relevant now (I have found some categorization errors), that type of cleanup will be for later...

> On 11 Jan 2021, at 12:55, Dominique Hazael-Massieux <dom@w3.org> wrote:
> 
> Hi,
> 
> As part of the Web site redesign, Denis, Vivien and I have been looking
> at some of the approaches we could take to make the TR page easier to
> consume - with a goal of bring this  as input to the redesign Studio 24
> is going to bring to the page as part of the overall site redesign. This
> message concludes with a short-term request for feedback .
> 
> Part of the challenge with the TR page is that we have over 1200
> technical reports on the page, which makes it hard to organize and make
> sense of.
> 
> Denis and I have been exploring the idea of bringing more structure to
> the list by recognizing that a significant number of individual
> documents can be grouped into more meaningful sets, along two main axes:
> * specification series (level 1, 2, ...)
> * specification "families" where a given "technology" is split in
> different documents (e.g. XQuery & XSLT, OWL, RDF)
> 
> (in many cases, these "families" can be manually inferred from use of
> common shortname prefixes, or common title subsets - moving forward, we
> would want to put in place a more systematic approach to defining and
> tracking these families)
> 
> When using this approach, and ignoring obsolete technical reports (those
> currently advertised as "retired" on the TR page), a first stab at this
> grouping produces ~ 280 entries (to be compared to the 1200+ full
> list or TR ) which sounds like it should be easier to grasp, and in
> general, help bring sense to our past and ongoing work.
> 
> The said grouping is described in
> https://docs.google.com/spreadsheets/d/1WlqmB1ZTUo-nqpZ-E_bMUHD_KCcHUC10c2uctsj9Cv0/edit#gid=0
> (exported as attached CSV as well) - this is based on TR data obtained
> on Dec 17.
> 
> Denis and I have been working on a wireframe-mockup of how a TR page
> reorganized along these lines would look like:
> 
> https://cdn.statically.io/gh/w3c/tr-pages/family-grouping/family-mockup/status.html
> 
> There is naturally a lot of improvements that needs to be brought to
> that design, but we thought it would help get a sense of what these
> families would enable.
> 
> We're primarily (and most urgently) interested in feedback from groups
> and spec authors on whether this is a reasonable way to organize the TR
> page moving forward. Given the timeline constraints of the redesign
> project, it would be great to get such *feedback before next Monday (Jan
> 18, 2021)*.
> 
> We're also interested in suggestions on how to improve the specific
> classification of specs proposed in the spreadsheet (ideally, towards
> reducing the number of families), but we have a lot more time for that
> work, on which we expect we would iterate on a more relaxed basis if
> this is indeed a viable way forward.
> 
> Thanks,
> 
> Dom
> <Classifying W3C Technical reports - Specs.csv>


----
Ivan Herman, W3C 
Home: http://www.w3.org/People/Ivan/
mobile: +33 6 52 46 00 43
ORCID ID: https://orcid.org/0000-0003-0782-2704