[Bug 7682] link tag: rel: associate pages about the same organization across many sites

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


Nick Levinson <Nick_Levinson@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|VERIFIED                    |REOPENED
           Keywords|                            |TrackerRequest
         Resolution|WONTFIX                     |




--- Comment #8 from Nick Levinson <Nick_Levinson@yahoo.com>  2010-03-28 20:33:36 ---
I'm not sure what needs to be made more formal for a spec. The need to find
content on one organization across many websites when many organizations may
have the same name is well known, and, when a canonical page is not agreed upon
or doesn't exist, is resolvable by each website offering extensive matchable
biographical data so a search engine can compare and match to distinguish
different organizations with the same name so websites about the same
organization can be found together. I've had difficulty getting UA makers to
respond to feature requests before HTML5 support. We need HTML5 support for
some of them to prioritize the feature. Thus, I'm requesting escalation.

Suggested title: link tag: rel: associate pages about the same organization
across many sites for searches without a canonical page and despite a
confusingly indistinct name

Suggested text:

Different websites may have pages about the same organization. Several
organizations (businesses, government agencies, institutions, ad hoc criminal
conspiracies, etc.) may have the same name and all may be written about on
multiple sites.

A link element naming the organization and providing data that is standardized
could help search engines organize their listings to reduce accidental
intermixing. It wouldn't be perfect; e.g., an organization may have listed its
name differently in different places; a website owner may erroneously enter the
wrong data; nationality may vary with a citizenship change; or its functional
headquarters and its legal headquarters may be far apart. But, in general,
listings with this element could be more successfully separated.

Writing and parsing the link element would be a bit more complex than with
other link elements, but I think this is manageable and the method I propose
has been applied elsewhere.

I propose that the rel value be "canonical-organization" and that its title
attribute be reserved for a special meaning and syntax. The title attribute's
syntax would be in the form of title="name: XYZ Greasy Spoon, Inc.;
headquarters: South Beach, Staten Island, New York, NY, US; ident-scheme: ;
ident: ;".

Each subattribute (e.g., "name") would be optional.

For the subattribute headquarters, if a subvalue is supplied, a nation would be
required. The nation would be represented by a standard code. One difficulty is
that an organizational headquarters is often inconsistently identified between
the functionally dominant one (e.g., where the CEO sits) and the legal one
(e.g., according to incorporation law), but that's probably solvable with
headquarters-main and headquarters-legal.

For the subattribute ident-scheme, a list of schema could be developed later,
perhaps each to be prefixed by a code for the scheme's nation and a hyphen.
Schemes could include privately-owned but widely available databases of
moderately-well-known organizations. Subvalues for ident-scheme and ident must
not be entered until a list of schema and the style of ident values for a
scheme is centralized and then the scheme must be in that list and ident's
subvalue must conform to the specified style.

If only whitespace or a null is between the colon and the semicolon, that is
equivalent to the subattribute not appearing.

A final semicolon before the closing quote mark is optional and may be imputed.

More subattributes might be added in the future, so page authors must not
invent new ones in the meantime.

No subvalue could contain a colon or a semicolon. If a one is needed or wanted,
a character entity must represent the colon or the semicolon.

Nations would be identified by standard two-letter codes. For nations that no
longer exist and do not have two-letter codes, e.g., Roman Empire and Van Lang,
longer codes must be used, since about 200 2-letter codes are already in use
and only 676 exist, and longer codes would prevent future conflict or
exhaustion. A list of deceased nations and their longer codes would have to be
established, possibly based on a standard gazetteer.

Multiple link elements with this rel value would be permitted, and UAs should
apply all of them. That permits multiple names (e.g., corporate and d/b/a),
ident-schemes, and idents to identify the one organization more certainly.

No rev value would be meaningful.

hCard and FOAF are too limiting, as discussed in Bug 7681 Comment 5, and don't
do what canonical-organization would. For example, FOAF and hCard each lack 3
of the 4 fields I proposed for the link element rel. Arguably, effort can go
into amending hCard and/or FOAF, but that seems more complicated, partly
because there appears to be a commitment to maintaining a nearly 1:1
relationship between hCard and vCard, which self-describes as stable, while
FOAF is oriented to online communities, requiring overcoming that to generalize
its use. Amending the HTML5 provision with equal effect is easier in simply
adding a new rel value and adding to where Web designers are likelier to see it
(HTML5).

Closely related is the corresponding value for humans, in Bug 7681.


-- 
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, 28 March 2010 20:33:38 UTC