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

> On 28 Nov 2018, at 16:31, Jiří Procházka <ojirio@gmail.com> wrote:
> 
> Adding to these good points, consider this blank node usage (using Turtle):
> 
> :joe :address [ a :Address;
>    :streetAddress "123 West Jefferson Street";
>    :postalCode "85003";
>  ].
> 
> :kate :address [ a :Address;
>    :streetAddress "123 West Jefferson Street";
>    :postalCode "85003";
>  ].
> 
> Someone please confirm, but I think using RDF semantics you cannot
> conclude the bnodes refer to the same address (which would be quite
> intuitive). As RDF is based on graphs, not tree, the "address" predicate
> plays a role as much as "postalCode" does. The first bnode means there
> exists an address with that streetAddress and postalCode and is an
> address of Joe. The second bnode means there exists an address with that
> streetAddress and postalCode and is an address of Kate. The RDF graph
> could as well be written like this:
> 
> [ a :Address;
>    :addressOf :joe;
>    :streetAddress "123 West Jefferson Street";
>    :postalCode "85003";
>  ].
> 
> [ a :Address;
>    :addressOf :kate;
>    :streetAddress "123 West Jefferson Street";
>    :postalCode "85003";
>  ].
My view is “yes”, and thank you for putting it so clearly.
I was concerned that people were looking at the properties of these fragments in isolation - but they never are.
There are always some properties that make use of these things.

In general I find the whole discussion rather strange, because it all depends on domain knowledge.
In deciding if these things can have the same identifier, you can bring in more and more properties for any given bNode until you are happy that it identifies some unique resource.
The knowledge brought is even making assumptions about the meaning of the predicates - is :Address about the sort of address that Lincoln made at Gettysburg?

I will happily assert that there is no general way of generating URIs for bNodes by using a function of the properties and their values in an open world.
:dad foaf:child 
 [ a foaf:Person;
   foaf:firstName “K”;
   foaf:surname “Kardashian”;
 ], 
 [ a foaf:Person;
   foaf:firstName “K”;
   foaf:surname “Kardashian”;
 ]
seems to do it.

But.
That doesn’t mean it isn’t a very useful thing to do, almost all the time.
Why?
So that people can recognise them when they see them again (maybe be resolving :dad a second time), or say things about them that actually have some useful meaning.

> 
> On 11/28/18 4:01 AM, David Booth wrote:
>> 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 17:37:14 UTC