[Bug 7681] link tag: rel: associate pages about the same person across many sites

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7681





--- Comment #7 from Nick Levinson <Nick_Levinson@yahoo.com>  2009-09-27 19:51:17 ---
It's already in the wiki and has been since the day this began, but
descriptions there should be brief, preventing detailing, and the wiki offers
two routes to acceptance, this being one, where it's filed as a spec
proposal/enhancement.

> - What would . . . [it] link to? You explained the semantics of the "title" attribute but not the "href".
I didn't add href because other rels and tags cover that. If adding href would
be helpful and wouldn't create a problem with rev, I don't mind adding it, but
I don't think it's needed.

Search engines would associate identical link elements from across the Internet
and present the results together. If a dozen websites link about "Chris The
Great" with the same birth/death dates, a search engine would assume they're
probably about the same person, while placing some other person with the same
name but different biographical data in a separate list of results. Results for
"Chris The Great" could then say "Six people have that name", present one or
two results for each, and then present more results matching the result you
clicked.

> - . . . wouldn't it be better to give the page [linked to] . . . a way to say what person it is about?
That option exists now. But linking to a page presumes the author trusts the
page they didn't author, and that trust shouldn't be required.

> - . . . If ["describ[ing] . . . the page containing the link"] . . ., it seems inappropriate to use <link> instead of <meta>.
A meta tag's grammar wouldn't be any simpler, meta seems less semantic, and no
present meta tag offers the set of fields.

A link tag in a head doesn't present a link to a visitor, but already (with
exceptions) is for search engines and other services to use to associate pages
(e.g., pages about friends) in results. The link tag educates the search engine
for more intelligent grouping. It is with that sense that this <link> was
proposed.

> - How can we be confident that people would want to use this complicated format, or want to use it in the first place[?]
The only ones who'd need to use it would be page authors and search engines.
Visitors would not use it, but would benefit from its use by others. Growth in
use could be gradual. The benefit begins as soon as a search engine sees two
websites with the same link tag.

It would be optional, and all the fields within it are optional. Some other
technologies, such a FOAF, are more complicated, even if revised to support
what this proposal would support. This one is shorter and easier for busy page
authors to apply.

Suppose you write fifty pages about Houdini Z. who flourished in the 1320s. You
could write <link rel="canonical-human" title="name: Houdini Z.; flourished:
1320s" /> into your template and copy the whole template fifty times, and add
your content. Or you could paste it into fifty heads; either way, you would not
have to search for a string within the body in order to put the tag next to a
relevant string. (You might need the tag on only one page, not all of them;
that would be up to the search engine in parsing importance. I'd recommend
having it on all, such as with a one-job template.) Suppose, while you write
your fifty pages of content, Mr. Putin, as a direct descendant of Houdini Z.,
writes one page about the same Houdini Z. and inserts <link
rel="canonical-human" title="name: Houdini Z; flourished: 1320s; ident-scheme:
Lesser Magicians; ident: 322" />. A search engine would guess that you and Mr.
Putin are writing about the same Houdini Z. And suppose Madonna writes about
Houdini Z., a California music producer who hit it big in the 1990s, and writes
<link rel="canonical-human" title="name: Houdini Z.; flourished: 1990s" />. A
search engine would conclude that that's a different Houdini and present it
separately.

Search engines have tried to group results in people searches, but haven't had
much success in writing algorithms to do it. A9 with Amazon's backing tried and
virtually gave up the service altogether. Results that try to group people
systemically tend to be awful. Ranking that puts famous people first means if
you want a less-well-known person you probably have to dig way down, and along
the way read every snippet just in case. Grouping would eliminate most of that
drudge with little inconvenience to searchers who want the most famous person.
That kind of grouping is already in use for some single-site search engines
(e.g., separating sales lit from downloads and repairs in a results list), but
that can work because a single site can impose per-page codes to support
grouping.

That benefit would motivate some page authors and search engines to employ the
feature once it's standardized.

Thanks.

-- 
Nick


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 27 September 2009 19:51:29 UTC