Re: W3C Linked Data Community Directory

Thanks Kevin.

That same geographic area/named place overlap/under-lap occurs worldwide.  I think that the Ordinance Survey has it right approach with the distinction between Spatial Thing(vocabulary) and Spatial Object(geography).  Eventually the geometry you want is that of a Cell Phone System (Tiled Hexagons, with a Point of Interest in the middle) as opposed to a Cartesian Coordinate "Wet Blanket".  You just have to make the Hexagons small enough to limit the radii of equi-error (isotherms, isobars, isotimbls maybe?).  The philosophical problem is that in a Cell Phone System signal overlap enables triangulation and tracking, the cells do not overlap.  Content negotiation between cell towers is automated.  So to put it another way, the tracking data channel is always open, but there is no mission critical systemic imperative to process the data in the channel. Angry Librarians, seem to have some company ... gotta go, if you need me I'll be on Earth.  

--Gannon



----- Original Message -----
From: "Ford, Kevin" <kefo@loc.gov>
To: 'Gannon Dick' <gannon_dick@yahoo.com>
Cc: 'eGov IG (Public)' <public-egov-ig@w3.org>
Sent: Tuesday, November 15, 2011 2:12 PM
Subject: RE: W3C Linked Data Community Directory

> ** scans street nervously looking for mob of angry Librarians **
-- No need.  Just curious if there was something we could do to help you more easily get to the data.

Should you continue to use ID.LOC.GOV data (and please do!), when it comes time to tackling national (and international?) divisions, I'll be interested to know how it turns out (and assist however I can). As I'm sure you've discovered, the Names scheme [1] at ID contains most geographic entries.  We do have a number of levels of (national and international) subdivisions, but unfortunately the source data does not necessarily record relationships (broader/narrower) between geographic areas.  For example, you can look up the individual components for "United States--Virginia--Spotsylvania County", but you won't find the relationships between those geographic areas expressed in the data.  

http://id.loc.gov/authorities/names/n78095330
http://id.loc.gov/authorities/names/n79022909
http://id.loc.gov/authorities/names/n80044566

In this sense, we certainly have a lot of work cut out for ourselves.

Cordially,

Kevin

[1] http://id.loc.gov/authorities/names




> -----Original Message-----
> From: Gannon Dick [mailto:gannon_dick@yahoo.com]
> Sent: Tuesday, November 15, 2011 2:41 PM
> To: Ford, Kevin
> Cc: 'eGov IG (Public)'
> Subject: Re: W3C Linked Data Community Directory
> 
> I suppose it would have been better to say "this uncovers a lot of new
> work to be done", since that is really what I meant.  Every Sovereign
> has a little bit different way of encoding their Subdivision
> vocabulary.  The LOC has some National Subdivisions, all optimally
> encoded and UN LOCODE has (almost) every Nation encoded, but with a
> flattened hierarchy. Trading value, goods and services for currency, is
> different from trading information. With the LOCODE structure, the
> return path vanishes behind you, if that makes any sense.  The current
> UN LOCODE covers 250 "Countries" with 4201 "Subdivisions" encoded by
> ISO 3166.
> 
> Sorry if it sounded like someone was not doing something they should be
> doing.  What I meant was ... lots of late nights and short weekends for
> everybody!
> 
> ** scans street nervously looking for mob of angry Librarians **
> 
> 
> Regards,
> 
> 
> --Gannon
> 
> ----- Original Message -----
> 
> From: "Ford, Kevin" <kefo@loc.gov>
> To: 'Gannon Dick' <gannon_dick@yahoo.com>
> Cc: 'eGov IG (Public)' <public-egov-ig@w3.org>
> Sent: Tuesday, November 15, 2011 12:21 PM
> Subject: RE: W3C Linked Data Community Directory
> 
> Dear Gannon,
> 
> > The main app has a 1) a Organization Nickname, 2) A link to the LOC
> > Subject Heading (Europe and North America at this time).  The LCSH
> > supplies broader terms. 3) A link to the narrowest available LOC
> > Vocabulary Encoding, which you can follow up to the LCSH 4) Leftovers
> > (the LOC has a lot of work to do), down to the narrowest Subdivision
> > defined by UN LOCODES (who also have a lot of work to do, and needs a
> > better definition of "peer").
> --  Can you explain "LOC has a lot of work to do"?
> 
> Cordially,
> 
> Kevin
> 
> 
> > -----Original Message-----
> > From: Gannon Dick [mailto:gannon_dick@yahoo.com]
> > Sent: Friday, November 11, 2011 3:42 PM
> > To: team-gld-chairs@w3.org
> > Cc: public-lod@w3.org community; eGov IG (Public)
> > Subject: Re: W3C Linked Data Community Directory
> >
> > I encoded the Community Directory (30 Members) on a spreadsheet and
> > converted to RDF/XML[1].  The app is the index of this URL[2].  It is
> > a transform of the RDF/XML to XHTML Strict 1.0.  The GRDDL of the
> > XHTML
> > (head) is also available[3], as well as a csv version of the
> > spreadsheet[4].
> >
> > There is a singlet example in RDF[5] and a Graph[6]
> >
> >
> > This was before I RTFM and found out that Callimachus uses a custom
> > RDFa+XHTML, naturally.  I did make one hard wired adjustment to the
> > XHTML Schema and that was a fixed "target" attribute which makes all
> > links open in a new window ... tabbed browsing was not available at
> > the time the spec was finalized.  I validated with Xerces and XSLT'ed
> > with Saxon.  All the source files are available here[7].
> >
> >
> > The data sources are: LOC (ID and LCSH), The National Atlas (US
> > Counties), USGS Earth Explorer (Int'l Subdivisions), Ordinance Survey
> > (UK Counties), US Census (US Counties), UN LOCODES Countries +
> > Subdivisions, and Wikipedia to resolve UN LOCODE problems.
> >
> > The main app has a 1) a Organization Nickname, 2) A link to the LOC
> > Subject Heading (Europe and North America at this time).  The LCSH
> > supplies broader terms. 3) A link to the narrowest available LOC
> > Vocabulary Encoding, which you can follow up to the LCSH 4) Leftovers
> > (the LOC has a lot of work to do), down to the narrowest Subdivision
> > defined by UN LOCODES (who also have a lot of work to do, and needs a
> > better definition of "peer").
> >
> > Notice the Nicknames are sorted by LOC ID, and that extension down to
> > Street Addresses would be a little pointless since no "knowledge"
> > would aggregate.
> >
> > Consider this a contribution from the non-Working Group eGov IG (and
> > have fun).
> >
> > --Gannon
> >
> > [1] http://www.rustprivacy.org/2011/phase/gld/cd/gld-cd.rdf
> >
> > [2] http://www.rustprivacy.org/2011/phase/gld/cd/ or
> > http://www.rustprivacy.org/2011/phase/gld/cd/gld-cd.html
> > [3]  http://www.rustprivacy.org/2011/phase/gld/cd/gld-cd.html.rdf
> > [4]  http://www.rustprivacy.org/2011/phase/gld/cd/gld-cd.csv
> > [5]  http://www.rustprivacy.org/2011/phase/gld/cd/gld-cd-eg.rdf
> > [6]  http://www.rustprivacy.org/2011/phase/gld/cd/gld-cd-eg.png
> > [7]  http://www.rustprivacy.org/2011/phase/gld/cd/gld-cd.zip
> >
> >
> > ----- Original Message -----
> > From: Gannon Dick <gannon_dick@yahoo.com>
> > To: "team-gld-chairs@w3.org" <team-gld-chairs@w3.org>
> > Cc:
> > Sent: Wednesday, November 9, 2011 4:04 PM
> > Subject: Fw: W3C Linked Data Community Directory
> >
> > Let me know if you want to add a full text regional identifier e.g.
> >
> > Nickname = 3 Round Stones Inc.
> > ID = [North America].[United States].[Virginia].[Spotsylvania County]
> >
> > It will come in real handy when there are thousands of entries; and
> > the time to do it is when there are 29 entries since the maintenance
> > is pretty easy.
> >
> > --Gannon
> >
> >
> >
> > ----- Forwarded Message -----
> > From: David Wood <david@3roundstones.com>
> > To: "public-lod@w3.org community" <public-lod@w3.org>
> > Cc:
> > Sent: Wednesday, November 9, 2011 2:58 PM
> > Subject: W3C Linked Data Community Directory
> >
> > Hi all,
> >
> > The W3C has launched a community directory of eGov projects and
> > suppliers:
> >   http://dir.w3.org
> >
> > The directory is built on Callimachus [1], a Linked Data management
> > system.  A SPARQL endpoint is available to authenticated users.
> >
> >
> > Regards,
> > Dave
> >
> >
> > [1] Callimachus: http://callimachusproject.org
> >

Received on Tuesday, 15 November 2011 21:52:37 UTC