DPUB: abstract role is confusing

[jnurthen]

Having an "abstract" role is confusing. The ARIA spec contains the following text Abstract roles are used for the ontology. Authors MUST NOT use abstract roles in content. The spec then defines a role="abstract"

This WILL confuse authors. The abstract role must be renamed.

[halindrome]

If we end up renaming this I am fine with it, but I disagree that this is confusing. An "abstract" is a well-defined term of art in the publication community. Every W3C spec, for example, has one. Every scientific paper has one. The term is somewhat overloaded, in that an 'abstract' in real estate has a different meaning, but we can ignore that in this context I think.

If anything is confusing, it is that ARIA exposes the concept of an 'abstract base class' for roles on an unsuspecting and uncaring public. The consumer community for ARIA Core are not people who write ontologies. They are document and application developers. Those people are content area experts. Anyone who is creating a document/book and wants to annotate it with the DPUB-related roles is going to know what an 'abstract' is. They may not know what an 'abstract base class' is. My counter proposal would be that we remove the concept of a 'abstract roles' from ARIA Core altogether. Call them something else, or just hide them in the ontology. Why are we exposing something we don't want our users to use? It's like saying "see this shiny button? DON'T PRESS IT!"

[TzviyaSiegman]

Well said, Shane. Assuming no changes to the master spec, the biggest risk is that role="abstract" will not be used by those who misunderstand the spec. The module authors are confident that we can provide clear usage rules for role="abstract" and that the publishing community will understand how to use it. This will hopefully lead to implementation of the role by a broader community. Adding this role presents no greater risk of use of abstract roles than does their presence in the master spec.

[iherman]

Coming from the world of ontologies and the semantic web, I must say I was confused hearing the term "abstract class"...

The ARIA spec relates to OWL. But there is no such thing as an "abstract class" in OWL! Of course, I know this term as used in object oriented programming, but reusing this term for OWL classes is actually a problem insofar as there is already a confusion in the community at large mixing OWL classes and object oriented programming classes. (E.g., OWL classes are not about validity checking of data structures, they are used for inferences. They are very different animals.) Having a W3C Recommendation that adds to this confusion is not helpful in general (regardless if this specific issue).

I agree that with @halindrome that the right way of solving this would be to consider changing the terminology in the ARIA specification.

(I obviously owe an apology not having commented on the use of this terminology earlier. Somebody in the Semantic Web community should have done this.)

[mattgarrish]

I'm also in agreement with Shane, but acknowledge my bias upfront being an editor.

In my experience, if a specification gets in the way of real-world use, it signifies a problem with the specification. I'm open to making the distinction between the noun and adjective forms we're discussing clearer, but, as Shane notes, the biggest problem I find is that abstract roles are defined with all the other types.

I'm sure we all know that, even conservatively, 99.9% of people who use a specification never read it in any depth, and people are more prone to just reading the names and definitions to see which roles fit their needs. Publishers will not be confused by the role abstract, but I'm more certain they will be confused by the concept of abstract roles and why they're listed with the general roles but can't be used (and have to be cross-referenced/drilled down into discover which are which).

We did remove that line about not using abstract roles from the publishing module, since there are none defined in it and I agree it's not helpful. It would help in the core spec to link that back to the list of restricted abstract roles, as unlinked terms are easily dismissed by skimmers.

I'd also like to repeat what I've said on the dpub list: namely that "summary" is not a great replacement. While an abstract is a kind of abstract, there are many kinds of summaries (also an abstract typically precedes and sets up the work, while a summary follows). But beyond that distinction, we also run into html usage. The table element used to have a summary attribute, and the details element has a summary child. Using the less precise word "summary" leads us down a different path of confusion, as far as I can see.

I'd also like to suggest that, if nothing else, the informative notes be reconsidered for the abstract roles. In one section you say normatively that they must not be used, but then you use normative language to say they should not be used (which implies they can if the case warrants) informatively.

[mattgarrish]

Since my last paragraph probably makes no sense outside my mind:

Content authors must not use abstract roles because they are not implemented in the API binding.

But yet:

NOTE landmark is an abstract role used for the ontology. Authors should not use this role in content.

[richschwer]

To @iherman. OWL does not rule the world on computer science terminology. Abstract classes or types have been around since well before OWL. ARIA's use of OWL is to define an inheritance model similar to abstract classes or types in software development. It is how ARIA inherits states and properties: http://en.wikipedia.org/wiki/Abstract_type

I support our use of the role abstract but to go that far over the cliff to win our argument is not going to help.

[halindrome]

@richschwer you are of course correct. And the use of OWL is actually orthogonal to the problem I was talking about. I just think we shouldn't be exposing the abstract types at all. Or they should be hidden in an appendix or something. End users can't use them.

[mcking65]

Hiding the abstract roles in the spec would make understanding the role ontology really difficult; I rely on them being there. Where would all the links to superclass roles go when the super class is abstract? If we are going to hide them, then we should redesign the ontology to eliminate them. It is hard to imagine that an "end user" of a spec is the kind of person that would be confused by the concept of an abstract role or the normative language prohibiting its use.

Matt King IBM Senior Technical Staff Member I/T Chief Accessibility Strategist IBM BT/CIO - Global Workforce and Web Process Enablement Phone: (503) 578-2329, Tie line: 731-7398 mattking@us.ibm.com

From: Shane McCarron notifications@github.com To: w3c/aria aria@noreply.github.com, Date: 04/22/2015 01:10 PM Subject: Re: [aria] DPUB: abstract role is confusing (#34)

@richschwer you are of course correct. And the use of OWL is actually orthogonal to the problem I was talking about. I just think we shouldn't be exposing the abstract types at all. Or they should be hidden in an appendix or something. End users can't use them. — Reply to this email directly or view it on GitHub.

[cookiecrook]

I recommend dpub-summary (see also #36) to avoid author confusion and name collision.

[sideshowbarker]

I recommend dpub-summary (see also #36) to avoid author confusion and name collision.

I agree with @cookiecrook here—both about using the dpub- prefix and about the name summary rather than abstract.

Rationale

Beyond the issue of author confusion, I think we don’t need to have an exhaustive list of highly specific granular roles to represent every specific part of a book or article that can be modeled.

There’s a reason the HTML language has just an aside element rather than footnote, endnotes, sidebar, pullquote, etc., elements; it’s not an oversight—the language was very intentionally restricted to providing just aside until such time as a compelling need for any more is actually demonstrated (actually, IMHO I’m not sure any compelling need even for aside has yet been demonstrated…).

if the intent here really is to provide AT users with ability to navigate through a document to this particular type of content, then it seems like a summary classification is sufficient to that purpose. Non-academic content also often includes summary content at the beginning of a document but doesn’t always (or maybe even doesn't often) label it as an “abstract“.

It seems like summary is the more general class that such content belongs to; so if we want to align with the design principle that the HTML language has followed—and the precedent set by the HTML language itself—that suggests using summary until such time as there’s a compelling need demonstrated for a more specific abstract value.

And I say all this not even being convinced yet that we need any new role here at all.

But if the plan it to continue try to push through these 30 (or whatever the number is up to now) new DPUB roles, then I’d suggest that plan will have a greater chance of actually ever happening if the roles start out being dpub- prefixed and if this specific one among those 30 or so new role values is named dpub-summary rather than dpub-abstract.

[TzviyaSiegman]

Thank you for your feedback. This issue has been resolved by editing the document to comply with the rules for extending ARIA (https://www.w3.org/WAI/PF/wiki/ARIAExtensions).