EARL use cases Re: [w3c-wai-er-ig] <none>

Sorry, this is long, but it attempts to address each of the questions Jim
raised about my response in turn (except the one where we seemed to agree).

enjoy (or ignore...)

Aaah. The suthoring tool can indeed do this any way it wants. But there are
about 250 million users of authoring tools. And there are many many different
authoring tools (as well as "the author's brain" for people who are really
smart and dediccated).

If all authoring tools were perfect by themselves, then linking the
information would not be a problem. But they aren't, and nor are all authors.
The point of EARL was to provide a mechanism where comments could be
generated by one or more users or tools, and the data could be readily
combined and used by yet another user or tool. Hence the linking problem. (In
practise, the <link> element solution is nearly worthless as it requires that
the person making a comment have control over the content they are commenting
about. There are solutions developed in areas like PICS ratings, which is a
similar problem space, that are much closer to what is needed).

In the authoring tool scenario, the user is at the other end of an interface
that they chose because it interprets the information in a way that makes
sense to them (much the same as diffferent users have different browsers to
interpret HTML for them).

In the search scenario, the same applies. Although there are only a handful
of search engines, and I suspect there are only likely to be ever be, there
are millions of users each making different queries on those search engines.
metadata-enabling them in general has proven to be useful, more so if there
is a trust mechanism invlved (as there was in PICS and is in EARL).

For identifying it outside of RDF you have the same methods - it is XML with
a namespace that uniquely identifies it. (and that's something that every
browser is learning to deal with). It can then be recognised by a PERL
script, passsed to a handler written entirely in python for some other syntax
(via a web service that converts between syntaxes) and presented in some new
and useful way. (As it happens, that's how Sean and I deal with it - he uses
N3 syntax, I prefer XML, and there is a web service that can convert between
the two so we can choose our tools - I get to use GraphViz and he gets to use
cwm).

And finally in terms of what gets embedded in a tool, "something" has to
interpret the EARL. If it is going to be machine-useful, then it needs to be
a regular format. We could have chosen any number of these, and the reasons
we went for RDF (and XML, of which RDF is a subset) had a lot to do with the
ready availability of parsers, especially as suited for authoring tools and
agents. In many tools I actually do expect a simple RDF parser to be
implemented, in many more it will be possible to use a web-based service to
do the parsing and find the useful information, based on a cut-down result
developed by an inbuilt cut-down parser. (Mozilla has an RDF engine which is
a part of its netscape heritage...)

I agree that it is critical that the user have control over what gets done
with information they are trying to make the machines deal with - real
control, not just theoretical control. I believe that in most cases they will
be happiets if there are a range of ttools that provide a range of user
interfaces, and the ability to customise them for the few who are interested
and capable of doing so effectively.



On Sun, 21 Oct 2001, Jim Ley wrote:
CMN's two cents worth...
  >   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.

  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.
  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.

  >   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.


-- 
Charles McCathieNevile    http://www.w3.org/People/Charles  phone: +61 409 134 136
W3C Web Accessibility Initiative     http://www.w3.org/WAI    fax: +1 617 258 5999
Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia
(or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)

Received on Monday, 22 October 2001 16:39:52 UTC