- From: Frans Knibbe | Geodan <frans.knibbe@geodan.nl>
- Date: Tue, 01 Jul 2014 14:48:03 +0200
- To: Gannon Dick <gannon_dick@yahoo.com>, "public-locadd@w3.org" <public-locadd@w3.org>
- Message-ID: <53B2AE03.5000501@geodan.nl>
On 2014-06-27 17:33, Gannon Dick wrote: > Thanks Frans. > > But I quickly changed my mind when I started noticing how addresses are formatted in scientific papers. They just use commas. > ==================== > Yes, in the scientific world, address components are treated as comma separated columns. That is not quite the same thing as comma joined rows (eigenvectors). It is terribly tempting to see address components as address elements. The set of street numbers on a street might be helpful for navigation ("third house on the left",etc.), but the "academic" use for this information breaks down globally. > > > I left off the country name on purpose, because it would not be needed within the country and could easily be added otherwise. > ===================== > And here, exactly, is where the global breakdown (components versus elements) occurs. I think calling it a breakdown is a bit too harsh. In this case, all addresses are known to be addresses in the Netherlands, because this is specified in the metadata of the dataset (using dcterms:spatial, perhaps other triples could solidify the relationship). It does take a bit of reasoning, but I think it should be possible for a consumer to add the country name automatically in case it is needed. The dbpedia entry for the Netherlands in turn gives access to country codes, should they be needed in some sort of address specification. It could be debatable whether an address without a country name counts as a full or complete address in the sense of the location core vocabulary (locn:fullAddress). Does anyone feel up to doing that? > > Acronyms for countries and languages are two or three character codes. The Code Pages can always be reduced to two dimensions, so for example [A-Z]{2} = 26^2 = 676 or [A-Z]{3} = 26^3 = 17576 < 133^2. The signifigance of this is that any [A-Z]{3} can be fully (over) subscribed by 133 unicode glyphs, which is to say the codeset will obey the Caley-Hamilton Theorem[1]. > > There is a little problem: see A bogus "proof": p(A) = det(AIn − A) = det(A − A) = 0. Virtual addresses and URL's manifest this way, but fail to prove the theorem, and if you can not use the theorem then you get undesired (not to say silly) convergence - everybody speaks English or lives in Albania, etc. > > --Gannon > > [1] http://en.wikipedia.org/wiki/Cayley%E2%80%93Hamilton_theorem > > > -------------------------------------------- > On Fri, 6/27/14, Frans Knibbe | Geodan <frans.knibbe@geodan.nl> wrote: > > Subject: Re: Using the core location vocabulary to query national address data > To: "Gannon Dick" <gannon_dick@yahoo.com>, "public-locadd@w3.org" <public-locadd@w3.org> > Date: Friday, June 27, 2014, 9:00 AM > > > > > > > > On 2014-06-13 > 19:48, Gannon Dick wrote: > > > > > > "Would it make sense to use HMTL tags for > formatting?" > > Yes, it would to me, because I am bone tired of look-alike > abstractions :-) > > At first I was thinking about using HTML to put line > breaks in an > address. But I quickly changed my mind when I started > noticing how > addresses are formatted in scientific papers. They just > use commas. > I think plain commas are nicer than fancy formatting > because an > address with only commas could embedded directly in any > text. To use > such an address to put on a mail envelope, one would > only have to > replace the commas with line breaks. > > > > It was rather less trivial then I thought, but I have > now managed to > add full addresses to the data set. For example, the > following query > returns all full address within a specified postal code > zone: > > > > prefix locn: <http://www.w3.org/ns/locn#> > > select ?full_address > > from > <http://lod.geodan.nl/basisreg/bag/nummeraanduiding/> > > where { > > ?address a locn:Address > . > > ?address locn:postCode > "1021GL"^^xsd:string. > > ?address locn:fullAddress > ?full_address . > > } > > > > (Click here > to issue this request in your web browser and see the > results) > > > > > > > > Regards, > > Frans > > > > > > > Cheers, > Gannon > > > > > > > > > Frans Knibbe > > Geodan > > President Kennedylaan 1 > > 1079 MB Amsterdam (NL) > > > > T +31 (0)20 - 5711 347 > > E frans.knibbe@geodan.nl > > www.geodan.nl | disclaimer > > > > > > > > ------------------------------------------------------------------------ Frans Knibbe Geodan President Kennedylaan 1 1079 MB Amsterdam (NL) T +31 (0)20 - 5711 347 E frans.knibbe@geodan.nl www.geodan.nl <http://www.geodan.nl> | disclaimer <http://www.geodan.nl/disclaimer> ------------------------------------------------------------------------
Received on Tuesday, 1 July 2014 12:48:42 UTC