RE: Question about philosophy

Thanks, this is a really good explanation and helps me realize why I've been so confused about whether and how to use @role. Even the spec itself (which, yes, I did read) doesn't really make this clear.

From: Matt Garrish [mailto:matt.garrish@bell.net]
Sent: Monday, April 13, 2015 7:06 PM
To: Bill Kasdorf; Nick Ruffilo
Cc: public-digipub-ig@w3.org
Subject: Re: Question about philosophy

There’s a difference between what @role allows and what validators allow. There isn’t a restriction on the values you can use per the specification, but HTML validators restrict the attribute to the set of roles defined in the ARIA 1.0 specification. Unrecognized semantics are ignored and AT either fallback to a recognized value in the attribute or to the implied semantics of the element, but you may still get the appearance of non-compliance.

It would be nice if unrecognized unprefixed values were errors and unrecognized prefixed ones not, but that’s not a determination we can make here, and not defined or required by ARIA.

At this point, though, we also fall into the problem of labels as prefixes. There is nothing to say who owns “dpub-“; it lacks a unique identifier. So slapping a “prefix” on your vocabulary isn’t even completely safe short of some additional extension modifier, or using RDFa prefixes.

But back to the original post, we made a determination that we want our publishing terms to be as general to as broad a publishing audience as possible to be in the core – specialized publishing needs are to be addressed later in a domain-specific manner. I think that’s as close to what Nick is after as we can get, and even it is arbitrary.

As I was trying to illustrate through abstract, how general or specialized you try to make terms isn’t a precise science. The more you claim you’re generalizing, the more difficult you make application and consumption. The more you specialize, the more redundancy and complexity you build into your system.

It’s easy to say all abstracts are summaries, but for whom is that helpful? It’s less information for the reader. It’s less specificity for the publisher. It’s problematic across domains leading to specialization.

Everyone is looking for the sweet spot, but I don’t know that we can find it through an arbitrary conceptual lens. We will go this far and no further, is hard to pin down at the end of the day. :)

Subjective, case-by-case determinations are here for the foreseeable future. And that means there will always be counter-argument/dissent no matter which one of precise or general you choose.

Matt

From: Bill Kasdorf<mailto:bkasdorf@apexcovantage.com>
Sent: Monday, April 13, 2015 5:55 PM
To: Nick Ruffilo<mailto:nickruffilo@gmail.com> ; Matt Garrish<mailto:matt.garrish@bell.net>
Cc: mailto:public-digipub-ig@w3.org
Subject: RE: Question about philosophy

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<mailto:public-digipub-ig@w3.org>)
Subject: Re: Question about philosophy

Matt,

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.

-Nick

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.

Matt

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

DPUB,

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
@NickRuffilo
http://Aerbook.com
http://ZenOfTechnology.com<http://zenoftechnology.com/>





--
- Nick Ruffilo
@NickRuffilo
http://Aerbook.com

http://ZenOfTechnology.com<http://zenoftechnology.com/>