end-user exploitation of EARL-mediated info scenario(s)

[I don't know how this thread got into the situation of having no title, but I
have re-titled the thread in accordance with my understanding of Jim's
question.]

At 12:26 PM 2001-10-21 , Jim Ley wrote:
>
> [quoting Charles...]
>> My 2c worth on the answers to the questions...
>>
>> On Sat, 20 Oct 2001, Jim Ley wrote:
>>
>>   I'm going to ask some questions about how EARL is to be used, which
>will
>>   hopefully allow me to be more focused on what my concerns are and
>>   therefore be more constructive:
>>
>>   Who/what is the audience for reports?
>>   What does this audience do with these reports?
>>
>> The immediate audience is primarily tools which interpret the EARL.
>
>So where's the user?
>
>This identifies one of the problems, we have different perceptions of how
>it is to be used, in Repair terms, it's not important how you get from the
>url to its report, that's up to the authoring/repair tool.  So the
>"linking" issue isn't a problem.

This linking is sensitive the the ease of implementation by the repair tool of
the machine-followable path, yes.

>In the use to aid accessibility directly for users (as opposed to repair)
>then you see search engines doing it, I see users doing it, I am big
>believer in the user being the best placed to utilise such information.

AG::

Then you have a verrrry strange model of user behavior.

Users are couch potatoes.  99-44/100% of users won't mess with the metadata
unless picked up in a search algorithm.  People operating through a layer of
Assistive transformation are at an added disadvantage in taking control of the
process, and many who would wish to operate the way you say just won't be able
to manage the complexity it imposes.

Let's get the record straight.  We tromped on all kinds of vendors' corns to
get various format specs and the UAAG to assert that the user has the
inalienable right to get into all the hair and micromanage to their heart's
content.  But part of selling this policy is the observation that so long
as we
make the author's preference easier to just accept, for the most part only
those who genuinely need to exercise detailed control will ever bother.

There has to be a "plain web" report presentation or the _content providers_
will rebel and won't agree to have their content ratted on unless they can
review and get comfortable about how the report is talkin' 'bout their
labor of
love.  This is more for the authors than for the users.  Most users won't
bother.  Please see my post from earlier this morning with regard to the plain
web presentation of EARL results.  It's a piece of the system that has to be
there.  For authors' comfort and for users' rights.  But for users, the plain
web presentation is only touched by a small fraction of those who benefit.

And for some LD users and others for whom a small majority of the Web actually
works, it is simply not a solution to first go to each individual page and
from
each of these navigate to the EARL based report on accessibility.  There
has to
be pre-filtering of the available stuff based on pre-collection of the
metadata, in order for the density of workable pages in what they _try_ to
browse, to come up to a level where it is at all worth the time to try.  So at
least for these hard-case communities struggling to get _onto_ the web (and
there is a not-small group of LD potential Web users for whom this is the
state
of the art) the coupling into search algorithms is essential to getting up
to a
minimum success level from where we are today.

The point of putting it in machine comprehensible structure is for downstream
machine processing.  The point of developing a common schema into which you
register or sientifically place the information is so that information from
multiple sources can more readily be combined.  But the whole thing has to be
carried out in a fishbowl of human-comfortable reporting or the machine
processes will not be trusted and the machine-comprehensible form won't be
used.  The system has to provide "operational processes" methods of ensuring
that what the machine is told is something that the humans involved should
have
to put up with, or the whole thing is a non-starter.

On the matter of recombinant information and documenting what you publish, see
the "avoiding the sidewalk closings on the way to the restaurant" scenario I
just posted to GL and then EO.  Yes the user should select what resources they
wish to use, and in fact have machine assistance in merging information from
different sites.  This _is_ radical.  We _do_ need to demand it.  The ability
to do this in the User Agent is only a matter of making the "son of MSAA"
protocol for AT extension of mainstream E&IT as sought by the U.S.
Accessibility Forum sufficiently schema-aware.  All you have to do is to look
at a few scenarios like the sidwalk closings scenario to realize it is a
disability access issue.  All you have to do is pop up from Web Services to
Grid Distributed Computing to realize it is endemic in everything about where
the Web is headed.  So this is just a matter of doing the
AT-with-mainstream-technology treaty right as an instance of "any function can
be done anywhere" Grid protocol architecture.  Small coordination problem? 
Yes.  But _it's happening as we speak_.  Doing it right is readily achievable
if we can just get the word out before the concrete is hard.  We should be
using the generation and exploitation of accessibility evaluation results as a
demonstration of all the key cogs in this next engine of internet progress.

Al

>This means I see an audience much bigger than yours appears to be - you
>have <100 search engines, I have >millions of users - and therefore I
>expect much more development, more choice and more users wanting to create
>something themselves.
>
>>   Does a query language need to be developed?
>>
>> Because this is RDF, we can rely on the existing and developing
>techniques
>> for querying RDF rather than inventing a specialised interface. (For
>> optimisation, simple tools may only implement "enough for EARL")
>
>Good, this I agree with absolutely.
>
>>   What happens if there's an alternative to EARL, also in RDF how do the
>>   users tools distinguish between the 2?
>>
>> If there are alternatives then there are going to be two processes for
>> interpretation. If it is in RDF then the namespace declarations are the
>key
>> (there is an issue on this at the moment based on whether tools are more
>or
>> less likely to understand Dublin Core RDF elements already).
>
>This is what I find unacceptable as it drastically increases the
>complexity of the tools, as you say you only need implement RDF "enough
>for EARL".  If that requires tools to cope with RDF.  If it was uniquely
>identifiable outside of the RDF then it would be much simpler, we can just
>pass it to the most appropriate processor, if we can't do this we have to
>pass it first to some general purpose RDF processor to know how to process
>it, and then it's either got to pass it on again to the various tools I
>want to use to process the actual reports.
>
>Do you see some single RDF processor existing on peoples computers?
>
>There are currently no mechanisms in the current User Agents that are
>similar, we either have the content coped with internally, or we have
>choice as to which other program to use, either through MIME-TYPE or
>protocol.
>
>I think it would be silly to require new user agent capabilities, when if
>we just stuck with what's possible now, we wouldn't need to get UA
>developers on board, or expect users to change their UA, they can just add
>in the tool.  This will make it easier to get a user base, and therefore
>encourage people to actually create these reports.
>
>Jim.
>

Received on Sunday, 21 October 2001 15:11:36 UTC