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

> On Mar 15, 2021, at 8:49 AM, Dominique Hazael-Massieux <dom@w3.org> wrote:
> 
> Le 15/03/2021 à 16:12, Ivan Herman a écrit :
>> My problem (I believe I expressed that before) is that the concept of
>> "family" may easily become too rigid. One specific example: "Digital
>> Publishing WAI-ARIA Module 1.0". It is under the WAI-ARIA family, put it
>> may also be put under Digital Publishing (in fact, it was done in the
>> DPUB IG).
> 
> That was indeed duly noted (although again, Digitial Publishing WAI ARIA
> Module claims itself that it is part of the WAI-ARIA family of
> specifications in its abstract). But multiple hierarchies wouldn't help
> give the kind of default organization that a single hierarchy does.
> 
>> I guess my feeling is that a "Family" should more act as a tag. Ie, the
>> same document should/could belong to several families.
> 
> There is (and will still be) a mechanism to tag specs that can be used
> to filter the list.
> 
> The question here was what could help give greater clarity on the
> default view of the TR page - the real comparison is not between the
> ideal classification of our technical reports (if one exists) and this
> one, but between this classification and the current complete lack of
> classification.

I  have similar concerns. Consider the following specs, which are spread across several families, but also directly related to each other:

JSON-LD 1.1 REC 2020-07-16 Json-ld JSON-LD JSON-LD
JSON-LD 1.1 Processing Algorithms and API REC 2020-07-16 Json-ld-api JSON-LD JSON-LD
JSON-LD 1.1 Framing REC 2020-07-16 Json-ld-framing JSON-LD JSON-LD
Time Ontology in OWL CR 2020-03-26  Time Ontology Time Ontology
Microdata to RDF – Second Edition Note 2014-12-16  HTML HTML
SHACL Abstract Syntax -- Note on Status of Obsolete Proposal ret 2017-07-20  SHACL SHACL
SHACL Use Cases and Requirements Note 2017-07-20  SHACL SHACL
Shapes Constraint Language (SHACL) REC 2017-07-20  SHACL SHACL
Linked Data Notifications REC 2017-05-02  Linked Data Platform Linked Data Platform
RDFa Core 1.1 - Third Edition REC 2015-03-17  RDFa RDFa
RDF 1.1 N-Triples REC 2014-02-25  RDF RDF
RDF 1.1 Concepts and Abstract Syntax REC 2014-02-25  RDF RDF
The RDF Data Cube Vocabulary REC 2014-01-16  RDF Vocabulary? RDF Vocabulary
SPARQL 1.1 Query Language REC 2013-03-21 Sparql-query SPARQL SPARQL
SPARQL 1.1 Entailment Regimes REC 2013-03-21  SPARQL SPARQL
RIF In RDF (Second Edition) Note 2013-02-05  RIF RIF
OWL 2 Web Ontology Language Document Overview (Second Edition) REC 2012-12-11  OWL OWL

There is certainly a case for having some of these specifications show up in multiple categories. I understand that you might be able to find them through a search, but it can be easy to get lost among them, particularly if relevant search terms aren’t necessarily apparent. Some documents certainly cater to different communities; for some JSON-LD is just another RDF serialization format, for others, it is something that should be distanced from RDF, as it can be thought of as it’s own format. Same for RDFa and Microdata to RDF.

Giving the community the ability to edit and/or update tags and families might be useful, and organizing based on common citations, or creating a meta-family that is populated through such analysis could be useful.

That said, I’m really supportive if this effort, as /TR is otherwise pretty opaque, and any effort at categorizing would be an improvement. Perhaps tags might show up as a UI element of the different families and/or related documents that could themselves be navigable.

Gregg

> Once the first phase of the TR re-design closes, we can certainly
> entertain a different default way of presenting our TRs if we find one
> that is better.
> 
> And if we find this family classification worse than no-classification
> at all, we can give that feedback to Studio24 to use the current
> un-grouped list for the TR page - that's one that will be built in any
> case since (as the presentation indicates) it will serve as a basis to
> filtered views.
> 
> Dom
>