On 21/10/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
> OK, I should rephrase that to "If it were a URL then that would be
> more practical for an href surely?"
You're only saying that because most implementations don't support LSID
URIs yet, but you already showed me a working implementation of it that
does make it practical for those users.
You are right, I'll concede that putting an LSID into a link would
have its benefits in certain contexts. If you look at some of the
broad and varied uses of species names [1], placing LSIDs in links *by
default every time*, would only serve to confuse and irritate users.
[1] http://microformats.org/wiki/species-examples
>>> However, providing a *direct* link to the resource described by the
>>> LSID isn't the intended aim of the microformat; the LSID is in there
>>> as metadata that describe a resource, while the normal hyperlink, if
>>> there is one, probably points to something else entirely.
>>
>> What's wrong with providing 2 links? One to the LSID, another to the
>> related information.
>
> How might that work, given that you probably don't want the user to
> see the LSID?
Why wouldn't you want the user to see it? What benefit does it provide
if a user can't do anything with it?
Just because the LSID isn't in a link or can't see it, doesn't mean
there's no benefit to the user. hCards are mostly useless to a user
unless they install special add-ins for Firefox, or use bookmarklets
or webservices etc. On their own, microformats don't do much. The
benefit comes when a computer is able to accurately parse the
information and act on it somehow. The user doesn't need to be able to
act on it directly.
That LSID implementation you showed me earlier seems like quite a good
reason to show it. The fact that it's not a widely deployed extension,
nor a widely supported URI scheme, is a rather minor point if you think
about how fast such implementations can spread. If you give users a
reason to add support to their browser and given that there is already
at least 3 separate LSID implementations, it probably will.
Yes, that's a good point; there's no reason why LSIDs shouldn't be
used in links. That's kind of a seperate issue. I'm thinking of
practical ways of implementing them within a microformat.
Just consider how fast the feed:, skype:, callto: and other URI schemes
have spread and became relatively widely supported in feed readers and
IM clients. My point is lack of widely deployed implementations now is
not a reason to avoid using it in the future.
Agreed.
What wrong with something like this structure?
<span class=="taxon">
<a href="/lutra_lutra/">View information about <span
class="species">Otters</span></a>
(<a href="lsidres:..." class="lsid">LSID</a>)
</span>
What's wrong with it? Nothing, as such. But what if you don't want the
second link? It's not practical or desirable to have a second link
after every occurrence of a species name. It would be akin to
requiring an ISBN link after every mention of a book, or an email
address after every mention of a person.
I've got nothing against including LSIDs in links, which I agree is
where they semantically belong, but they also need to be attached to
non-link elements too. That's the problem that the microformat is
trying to address.
An alternative implementation using the "abbr design pattern" has also
been suggested. What to folk here think of this? Here's what the abbr
design pattern is:
http://microformats.org/wiki/abbr-design-pattern
The datetime design pattern is also pertinent:
http://microformats.org/wiki/datetime-design-pattern
Here's how it might work:
<span class="taxon">
<abbr class="lsid" title="urn:lsid:ubio.org:classificationbank:1092045">
Deuterostomia
</abbr>
</span>
Semantically, it's not dissimilar to the use of abbr with dates as
described on the abbr and datetime design pattern pages.
Feedback on this most welcome.
Charles
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
