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> 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 <nickruffilo@gmail.com>
> *Sent:* Monday, April 13, 2015 3:01 PM
> *To:* mailto:public-digipub-ig@w3.org <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/>