Re: Dictionary link types

to follow up on what Murray Maloney said:

> At 04:25 AM 23-09-97 -0400, Daniel Dardailler wrote:
> >
> >> Example:
> >> <link href="dictionary.xml" rel="dictionary (abbreviation, phonetic)">
> > 
> >Anyone wants to argue whether or not a syntax like:
> >
> ><link href="dictionary.xml" rel="dictionary" class="abbreviation, phonetic">
> >
> >is better or worse ?
> >

> I would argue that both syntaxes are worse.  LINK was never
> intended to do RDF, so we should probably not try to force-fit
> RDF into LINK.

> In other words, it seems that the problems that the proposed
> solutions are addressing are best solved through a mechanism
> for asserting and locating resources. That is what RDF is
> intended to do.

Murray, can you expand a little on how RDF would connect this
connection?  I am behind in my RDF homework.

I suspect that the "accessibility interest group" in the large
is more interested in seeing that the connection gets connected
than in exactly how it gets connected.  Just so long as something
that the specifications allow clicks and that browsers and
websites use it.

I myself would go one step further with this.  Wearing my
accessibility advocate hat, I know I would want a good capability
for the definition and circulation of dictionaries such as speech
and Braille users would want access to.  On the issue of whether
the specifications should enable redundant capabilities via LINK
and RDF, I think I would want to abstain and make the
architecture group within the W3C make that call.  I would want
whatever they thought would lead to a widely deployed dictionary
publication and use capability linked with the WWW in the
shortest possible time.

If you specify only one way to do it and you have picked a
winner, narrowing the range of choice reduces the cost to
implement and probably the calendar time to widespread
implementation.  If you have picked a loser, the capability may
be delayed in implementation or never comes to market.  There is
some merit to the WWW supporting the competitive range of
solutions and not trying to guess the winner too early.

Received on Tuesday, 23 September 1997 11:29:44 UTC