FD 530
identifies a Faroese ship. It is a unique identifier, but only within the context of Faroese ships.
Googling for FD 530
will return information about much more than this ship.
The radio call sign XPUF
is glabally uniqe within ship radio call signs,
googling for XPUF
will still give about 100 other hits.
Faroese companies and organisations are identified by a number called a vtal (a.k.a. v-tal, vinnutal...)
Searching for 357421
gives a thousand
hits.
Searching for
vtal 357421
gives only one hit, but that is plain luck, we might have got thousands of irrelevant hits.
What we need, is a Uniform Resource Identifier to ensure global uniqueness of the ID of our company.
One obvious candidate, is the URL of the description of the company: http://www.gulu.fo/Virki.vit?VirkiId=357421. But there are a few problems with that solution:
Gulumeans
yellow, which is a reference to the yellow pages in the phone directory, which is not a complete company listing.
Vit.
I suggest that Eindarskránni register the domain reg.fo, and assign subdomains ship.reg.fo for the ships register, vtal.reg.fo for companies, pf.reg.fo etc. Alternatives to reg are skrá and register, but I prefer reg because it is short and uses ASCII characters only. Use ships in English because shipping is a very international business.
Then, http://ships.reg.fo/FD/530 should redirect to http://www.skipalistin.fo/SkipInfo.asp?SkipID=3929 and http://vtal.reg.fo/357421 to http://www.gulu.fo/urslit.php?fvirki=357421.
ships.reg.fo should probably run on the same server as www.skipalistin.fo, and vtal.reg.fo together with www.gulu.fo. It is very important that the government owns the domain name, but not at all important that it runs the servers.
Technically, the information about the ship could be in an HTML page at http://ships.reg.fo/FD/530. But within a couple of years, we will be able to search in the semantic web. When we get there, it becomes important to differentiate between the ship built in 1938, and the web page describing it, from a later date. We do not want the ship to appear in a list of ships newer than 1980, and we do not want the web page in a list of pages from before 1980. Thus, there must be a redirect, if nothing else, so at least from http://ships.reg.fo/FD/530 to http://ships.reg.fo/FD/530/index.html.
Skipalistin should publish the URI as unlinked plain text, "URI: http://ships.reg.fo/FD/530", and in the HTML HEAD element: <link rel="DC.subject" href="http://ships.reg.fo/FD/530" />
Because the call sign identifies a ship globally, creating a Faroese URI for it is something of a waste. itu.int is probably the right place for this.
Skipalistin could start coding <link rel="DC.identifier" href="http://call-sign.maritime.itu.int/XPUF" /> without even asking ITU. But a standard is only useful if it is widely used, that will only happen if the URI is published by the ITU on NORDSOEKI.
We have a strong maritime tradition—maritime ICT might be one of our better chances to make a difference internationally.
Maybe Eindarskránni should consider an offer to the ITU: hosting callsign.maritime.itu.int,
mmsi.maritime.itu.int and epirb.maritime.itu.int, redirecting
http://callsign.maritime.itu.int/XPUF to
http://www.itu.int/cgi-bin/htsh/mars/ship_search.sh?sh_callsign=XPUF,
http://mmsi.maritime.itu.int/231232000 to
http://www.itu.int/cgi-bin/htsh/mars/ship_search.sh?sh_mmsi=231232000
and
http://epirb.maritime.itu.int/231232000 to
http://www.itu.int/cgi-bin/htsh/mars/ship_search.sh?sh_epirb_id=231232000
(The load on those hosts would probably be quite light, if performance becomes a problem, they could run very efficiently with custom-written C++ servers, rather than general purpose web servers.)
The same applies to Norway: http://www3.brreg.no/oppslag/enhet/detalj.jsp?orgnr=985821585 is a very poor URI for Norid.
Many of the same problems as the Faroese URLs.
And the URL contains the irrelevant information that the register is presently
in Brønnøysund. The digit 3
is probably a more or less random result of server pooling.
See Wikipedia: Uniform Resource Identifier.
Why URLs are good URIs, and why they are not
Jan Egil Kristiansen, Styrheim