- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Mon, 15 Mar 2021 10:14:48 -0700
- To: Dominique Hazael-Massieux <dom@w3.org>
- 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>
- Message-Id: <033A00F2-4806-4311-A064-E25E2CD83FE9@greggkellogg.net>
> 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 >
Received on Monday, 15 March 2021 17:15:05 UTC