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

> On 29 Nov 2018, at 21:45, Pat Hayes <phayes@ihmc.us> wrote:
> 
> On 11/28/18 10:31 AM, Jiří Procházka 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 
> 
> That is correct, you cannot infer this in RDF.
> 
>> (which would be quite intuitive).

> Because you know quite a lot about postal addresses, including for example that a street name and a postcode uniquely specify a street and that a number plus an identified street is a unique address. To say this kind of stuff you need more expressivity than RDF provides. You should be able to do it in OWL.

One source of the intuition may be just common sense reasoning as Pat points out above.
Such reasoning should be suspect in the a global context as we are going outside of the
local area where that type of reasoning is good, and moving into a global space: so for
example there may be two countries that have a West Jefferson Street or there may be two
apartments at that number. The identity of an address may not be that well defined,
especially not globally:  I remember hearing that Japanese addresses have very different
fields to US ones.  Thus if one wanted an address ontology it may well need a light weight
RDF upper ontology, with national OWL subclasses using keys.
https://www.w3.org/TR/owl2-syntax/#Keys

But there is another intuition that comes from OO or even functional programming from
thinking of algebraic data types. Anthony Moretti made that point for Swift in another
post in this thread here
https://lists.w3.org/Archives/Public/semantic-web/2018Nov/0313.html

One could make a similar argument in Java, JavaScript or Scala. In such languages the
identity of objects can only be determined by fields of the objects, that is arrows going
*from* the object to a literal or another object, as there is no way to determine what
objects are pointing to an object O from within O: there is no global object index.  So
someone coming from that background would find it odd that arrows pointing to a blank node
could make a difference as to the equality of that object.

The similarities between these different programming paradigms - RDF's logical , FP's algebraic and 
OOs state  based  architecture - can be quite confusing as there seem to be obvious mappings 
that nearly work  but not quite.
  For example an object's reference could be thought of as an unnamed node in the memory
graph of the state machine, and this could be thought of as referring to a real object in the world, say
to a physical address. But one never merges two Java VMs as one does two graphs, unless
one builds OO programs based on data coming from resources returning RDF representations...

So it may  be that it is not so much easier RDF that is needed as time working out how these
paradigms fit together, as we need people from these paradigms to work together.
I have found some leads in Category Theory that may help there, as it
has a model of OO as Coalgebraic, as FP as algebraic and a general theory of the structure of logic
with Topos theory (for example, Institution Thory is another), and morphisms between these have
been developed.

> 
> Pat Hayes
> 
> 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";
>>    ].
>> 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
>>> 
> 
> -- 
> -----------------------------------
> call or text to 850 291 0667 <tel:850%20291%200667>
> www.ihmc.us/groups/phayes/ <http://www.ihmc.us/groups/phayes/>
> www.facebook.com/the.pat.hayes <http://www.facebook.com/the.pat.hayes>