RDF for transcoding Re: Access Key alternative -in the wrong place?

Trimmed cc list. Put PF in Bcc - they are member private and this thread is
public. Please follow up to one or the other (my preference is to keep the
conversation on public topics on the GL list, so I don't have to republish if
I want to show stuff to people afterwards :-)

On Mon, 12 Jul 2004, Richard Schwerdtfeger wrote:

>Browsers need to map RDF to an API to describe how to interact with an
>object. This requires a good RDF parser.

chaals:
Yes, but not all browsers will want to do transcoding. And for so long as
there are limited applications of it they can be handled with a limited
parser, if necessary as middleware through Web Services. (This approach to
middleware has the benefit that you can use a relatively simple XML tool
at the client)

Rich:
>Furthermore, it is becoming less likely that transcoding will be done in
>the middleware to process it since more often than not the UI will be
>constructed on the client.

Chaals:
As browsers incorporate good RDF parsers or use parsers that are on the
platform I don't see this as a long-term problem.

Amaya already incorporates Redland, which is a good RDF parser. There are
others available. Jena is widely used and I have had students incorporate it
in a number of tools in Java with little difficulty. The W3C Annotea effort
is moving to implementation in Mozilla, which I expect means including a full
RDF parser either by updating what they have or changing it for a different
toolset. There is work being done to put RDF parsers into mobile phones (I am
waiting for one so I can replace my contacts and calendar with a
better-integrated and more useful system, and run a couple of other
applications on my telephone).

There are always the Treehugger approach of building the parser in XSLT, or
the GRDDL approach of using XSLT as the glue between a page and a parser,
since XSLT is widely implemented. The fact that Treehugger isn't a complete
parser is probably not a barrier for the specific use case of treating a
known set of transformation data such as SWAP's. If there
are a few other bits of transformation data floating around (an EARL
statement that a particular table is a layout table can be taken as a cue
to transform that table to CSS, for example) I can add those. If there is a
lot of it then it suggests that there are a number of people planning to rely
on a parser and the value case for having one is made "ipso facto".

And as Jim says, we are talking about assistive applications - these have
almost always involved installing extras in the system, which makes the
problem more one of packaging than parsing.

So I don't think the parser problem is a real barrier to implementation.

I do think that interoperability of vocabularies is important. But I can
readily take the RDF produced for SWAP, other RDF produced by another system
that does the same thing, and put the two together to suit whatever system I
happen to be using.

This will of course become easier when the Data Access Working Group releases
a standardised query language that we can expect all parsers to support - and
so far that group is on track with their milestones, andd it includes a
number of developers who have implemented several query languages in their
parsers already.

Tonight I am working on a tool to convert between MUTAT and AccessValet's
EARL output and the latest spec, which is what Hera and Axforms produces. I
believe that MUTAT and AccVerify produce the same variant, so this will bring
interoperability between the five tools' results (MUTAT needs some bugs
fixed, and Axforms needs some bugfixing and relies on Xforms being present,
so I don't expect either of those tools to get much real use for a few
months, but the other three are all used). When I publish those I hope they
will serve as easy examples for someone who wants to merge between (say) SWAP
and an EARL statement about layout tables.

Cheers

Chaals

>             Jim Ley wrote:
>
>Richard Schwerdtfeger <schwer@us.ibm.com>
>>Another concern that is growing for me is RDF. One of the problems we
>>are faced with on RDF is that NO browser supports it.
>
>I'm not exactly sure how you suggest browsers should or need to
>support RDF for this, it's not being served up to a user as bare RDF,
>but simply using RDF to provide useful additional metadata.
>
>The metadata need not be consumed by mainstream browsers, indeed I'm
>not sure what usefulness mozilla would have in doing so to the
>majority of its users, however it's easy to extend the browser with
>plugins to provide the functionality in an AT sense.

Received on Monday, 12 July 2004 18:52:24 UTC