W3C home > Mailing lists > Public > semantic-web@w3.org > November 2018

Re: Blank Nodes Re: Toward easier RDF: a proposal

From: David Booth <david@dbooth.org>
Date: Tue, 27 Nov 2018 22:01:39 -0500
To: semantic-web@w3.org
Cc: Nathan Rixham <nathan@webr3.org>
Message-ID: <b323cf4f-a6be-674f-683d-b4e0343f5de7@dbooth.org>
On 11/27/18 2:04 PM, Nathan Rixham wrote:
. . .
> Here's an extract:
> {
>     ...
>    "name": "County Assessor's Office",
>    "address": {
>      "@type": "PostalAddress",
>      "streetAddress": "123 West Jefferson Street",
>      "addressLocality": "Phoenix",
>      "addressRegion": "AZ",
>      "postalCode": "85003",
>      "addressCountry": "US"
>    },
>    "geo": {
>      "@type": "GeoCoordinates",
>      "latitude": 33.4466,
>      "longitude": -112.07837  },
> }
> . . .
> [To] have the same address or geo coordinates published on tens of 
> thousands of different websites, all using a different ID (uri) would be 
> a huge, horrible, mess.

Not so fast.  Two points:

  - Unless you make a unique name assumption with URIs, that huge, 
horrible mess is pretty much the situation we already have using blank 
nodes.  Except that in some ways the current situation is *worse*, 
because the same data loaded twice cause duplicate triples (non-lean), 
whereas that would be automatically avoided if URIs were usesd.

  - Those same addresses don't have to use different URIs on different 
web sites.  If we have a standard way to generate URIs for them, based 
on a natural key (or composite key) that is typically formed from the 
constituents of the n-ary relation -- the components of the address, for 
example -- then all those websites could automatically use the *same* 
URI for them.  Tools could do this automatically whenever the user 
writes an n-ary relation, like the JSON-LD example above.  And that 
would be a *big* improvement over the current situation.

David Booth
Received on Wednesday, 28 November 2018 03:02:01 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:42:03 UTC