W3C home > Mailing lists > Public > public-digipub-ig@w3.org > April 2015

RE: Question about philosophy

From: Bill Kasdorf <bkasdorf@apexcovantage.com>
Date: Mon, 13 Apr 2015 21:55:01 +0000
To: Nick Ruffilo <nickruffilo@gmail.com>, Matt Garrish <matt.garrish@bell.net>
CC: "DPUB mailing list (public-digipub-ig@w3.org)" <public-digipub-ig@w3.org>
Message-ID: <CO2PR06MB572CCA2A5161BDCA85E34C5DFE70@CO2PR06MB572.namprd06.prod.outlook.com>
One other important point is to keep the _purpose_ in mind.

The purpose of DPUB is to advise the W3C on things that could make the Open Web Platform work better for publishers.

One of the things we've determined would be helpful would be to expand the use of @role in the context of ARIA.

The purpose of @role in ARIA is to enable Assistive Technology (AT) to present content meaningfully to its users.

While I might have all kinds of other things I might want to do with an attribute like @role—in terms of workflow, or repository modeling, or any number of other purposes—the purpose of _this_ discussion (the one where we bumped into the "abstract" collision) is specifically the expansion of the vocabulary to use in @role in the context of ARIA.

Another discussion might be whether we would recommend changes to the @role attribute itself, the purpose of that being to make it easier to use @role for other purposes, or to use arbitrary or domain-specific vocabulary (and if so, how) without undermining ARIA, but that is separate from the ARIA-based discussion, imo. And I'm not sure we want to go there. Thus far, DPUB has not gone there.

Others are welcome (encouraged!) to correct me if I've misrepresented this.

--Bill K

From: Nick Ruffilo [mailto:nickruffilo@gmail.com]
Sent: Monday, April 13, 2015 4:19 PM
To: Matt Garrish
Cc: DPUB mailing list (public-digipub-ig@w3.org)
Subject: Re: Question about philosophy


Thank you.  Just to be clear - we do need to have a discussion on how to best deal with "abstract" but that wasn't the initial goal of my question (so all these comments are probably VERY relevant to that thread).

My question is a little bit of a higher level - which you addressed in your first statement - is about trying to adapt existing publisher-used definitions to the spec, or to figure out what the most logical structural constructs should be - and then make sure those fit publisher definitions.

Again - I have a personal lien, BUT see value in both sides and am more seeking clarification so that I can ensure my thinking is in line with the group.


On Mon, Apr 13, 2015 at 4:10 PM, Matt Garrish <matt.garrish@bell.net<mailto:matt.garrish@bell.net>> wrote:
Hi Nick,

A concern in this approach is that you can abstract things away to unhelpfulness. (couldn’t resist!)

How precise or how general to be is a question that has to be asked of any ontology, of course, but there are pros and cons to weigh. I certainly don’t disagree with the notion that an abstract is a kind of summary, but a summary is also many other things in turn.

If the goal is to clearly and unambiguously identify the structures of a document for publishing, what summaries am I going to be presented with? An abstract is a summarization that precedes the work and introduces it. A “summary” arguably is a concluding section that summarizes the findings of the work. They’re now equal, and maybe that’s okay. But what about summaries of tables and figures that explain the structure/nature? Are we reintroducing a new flavour of the summary attribute from HTML4 by consequence? Is it akin to the “page summary” mentioned in the ARIA spec? Do all these work together harmoniously?

Further complicating the discussion is that ARIA has real-world application in AT, so being too general can lead to unwanted consequences. It’s not just about names and definitions.

I’m not wedded to abstract by any stretch of the imagination, but I’m concerned that it was added to edupub for a reason, and summary was not. If we change, we need to be careful that we aren’t changing the usefulness, and not falling into the next trap of being called “too general”. By comparison, “part” was called out for not being specific enough, so it’s been hard to clearly establish where roles have to fit for inclusion.

What you propose of generalizing as far as we can would be ideal in an ideal world, but I’ve yet to see the problem of language having many meanings depending on context elegantly solved.

But the issue with abstract, as I understand it, is not that it has too many possible meanings. I don’t think that’s been raised as problematic, but that ARIA has a group of roles it calls “abstract” that are not to be used in the role attribute. Even though none of the publishing roles are abstract in that sense, the concern, as I understand it, is that it will perhaps lead to some set of web developers not using it, or wondering how the two relate.

We are encroaching on a model that was devised for classifying a certain set of roles, in other words. A case of adjective versus noun confusion, as it was succinctly put at one point.


From: Nick Ruffilo<mailto:nickruffilo@gmail.com>
Sent: Monday, April 13, 2015 3:01 PM
To: mailto:public-digipub-ig@w3.org
Subject: Question about philosophy


My apologies for a long-winded, difficult question, but I think it's important (at least to me, in understanding things).  This came up during our meeting today and I was requested to put it in an e-mail so that we could discuss.

My question ultimately boils down to - what is the philosophy of the DPUB group in defining document standards?  Is it to take the existing mechanisms and lexicons and build a format that fits that mold, or to utilizing existing knowledge and build an ideal document structure that provides a mechanism for all existing concepts.

Expanding the explanation/question

My apologies if I use any terminology in an incorrect way, my goal is NOT to try to define/redefine terms, I'm simply noting them in hopes to make an example.

One of the terms noted today was ABSTRACT.  It is a word that Dictionary.com has over 16 definitions for, some of them oddly contradictory.  Within publishing, it also carries different meanings based on context (law, fiction, non-fiction, etc).

There are many solutions to this problem, but, using the two cases I noted above, the direction of solutions would be different:

Fitting the existing mold:
If we were to fit the existing mold, a solution may be to use prefixes.  "law-abstract" "fiction-abstract" "aria-abstract" etc.

Creating a generic ideal:
Going with the other extreme, DPUB would drop all uses of abstract and would boil each abstract into it's "raw" form.  For example, some ABSTRACTs may be SUMMARIES.  Some may be "PURPOSE_STATEMENTS"  Honestly, I don't know enough about the different definitions of abstract to even begin proposing alternatives.

Building the Tree of Terminology and future-proofing
What my question ultimately stems from is - how are we approaching solutions.  you can build a tree from the roots, or you can build it from its farthest branch.  Both take very different paths.

The way I think about a document/package is a tree with many webs within.  If you can understand why each branch is happening and what goes down each branch and are clear and consistent in your word choice (of which I do realize is terribly difficult in English) then you create an amazingly rich and expressive way of defining terms so that their value is maximized to both the human and computer which will ultimately read this document.  Like in real life, if you have tree branches that overlap, your tree is inefficient.  It will most certainly not die, but, if you create the most efficient tree possible, it will not only save you time, but you will also resolve competing branch issues.

Huh? I still don't get what you're asking
If i wasn't clear enough, please let me know.  While i have my opinions, I'm more interested in what the philosophy has been up to now and what it hopes to be going forward so that I can do my best to align my thinking with what is best for the group.

- Nick Ruffilo


- Nick Ruffilo


Received on Monday, 13 April 2015 21:55:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:35:59 UTC