W3C home > Mailing lists > Public > spec-prod@w3.org > January to March 2021

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

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Mon, 15 Mar 2021 10:14:48 -0700
Message-Id: <033A00F2-4806-4311-A064-E25E2CD83FE9@greggkellogg.net>
Cc: Ivan Herman <ivan@w3.org>, spec-prod <spec-prod@w3.org>, public-website-redesign@w3.org, Denis Ah-Kang <denis@w3.org>, Vivien Lacourba <vivien@w3.org>
To: Dominique Hazael-Massieux <dom@w3.org>
> 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.


> 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

Received on Monday, 15 March 2021 17:15:06 UTC

This archive was generated by hypermail 2.4.0 : Monday, 15 March 2021 17:15:07 UTC