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

Hi Henry,
Can we explore a bit of this some more please:

> On 3 Dec 2018, at 09:16, Henry Story <henry.story@bblfish.net> wrote:
> 
> 
> 
>> On 3 Dec 2018, at 00:03, Anthony Moretti <anthony.moretti@gmail.com> wrote:
>> 
>> That's interesting Henry, I tried to think more about the example you included in your message. Is what you're saying due to all properties having inverse properties?
>> 
>> So the example could also be written as:
>> 
>>     var a = {
>>         type: Address,
>>         streetAddress: "123 West Jefferson St",
>>         addressOf: Joe
>>     }
>> 
>>     var b = {
>>         type: Address,
>>         streetAddress: "123 West Jefferson St",
>>         addressOf: Kate
>>     }
> 
> That is one way of thinking of things. 
> 
> RDF (without OWL) knows very little (nothing?) about which properties are essential to a type. It is
> a graph or relation. What it knows is that two non identical URIs could refer to different things, and
> it knows the identity criterion for a set of Literals (the xsd ones).
> 
> So the policy is: if something could be different don't assume it is the same: the generic RDF reasoner
> should not exclude a model of what the graph means.
> 
> With blank nodes the reasoner can come to a few more conclusions. Because blank nodes can only appear
> in the graph in which they appear and not outside of it, all the information about them is available from
> the graph. And so a blank node can only be distinguished by how it relates to other nodes in the graph.
> Furthermore the graph is immutable, so the information that is there is all there is.
All the examples I have seen seem to be very small, and in isolation, which is not usually possibly, because you are unlikely to get to the blank node without it being attached to something.
The Joe/Kate as properties to the blank node has been mentioned.
But in what sense in general is the graph immutable?
 [ a "PostalAddress”;
      :streetAddress: “1 High St",
      :addressLocality geo:london;
 ];
Seems typical of our discussion.
But what if I also later get a triple
geo:london :inRegion geo:ontario .

If you are only talking about blank nodes that have only literals attached, that wouldn’t be very useful, I would have thought?
(Especially as you can’t attach Joe or Kate to them.)

Best
Hugh
> 
> If your graph says there is a white cat and there is a cat, then that will be true in all models where there
> is a white cat. So adding there is a cat, adds nothing. If you meant to say there are two cats, then you would
> need to add a relation between the blank nodes.
> 
> 
>> 
>> An implementation of ==() for Address would know which fields were relevant to the equality of Addresses and which were not, so it would ignore the addressOf field. It also shows that a check for structural equality is often too simple, ==() is often type dependent.
> 
> That's what OWL inverse functional properties and keys allow you to do: specify which "atttributes" determine the
> identity of an object of a certain type. If the statement that the pair us:streetAddress and us:postcode formed a key
> were written out in OWL and made easily available the OWL reasoner would then be able to deduce that Joe and 
> Kate lived at the same address.
> 
>> 
>> Because these are blank nodes we have access to all the properties that point to them and it would be possible to check for inverses prior to checking for equality I think.
>> 
>> I do see things through the lens of OO though, so it's entirely possible I'm missing a point being made, if so please let me know.
> 
> OWL is kind of a declarative Object Oriented Language in the sense that OO comes with a notion of classes and inheritance if that helps :-)
> 
>> 
>> Anthony
>> 
>> On Sun, Dec 2, 2018 at 3:00 PM Thomas Passin <tpassin@tompassin.net> wrote:
>> On 12/2/2018 4:31 PM, Henry Story wrote:
>> > 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.
>> 
>> I don't think that this is quite right.  The usual objects in OO
>> languages know their parent *type* or (prototype).  They don't know
>> about any linkages to other objects unless properties are assigned that
>> hold that information.  And it's common to provide for such linkages.
>> Just think of doubly linked lists, or the XML DOM.  True, there is 
>> usually no built-in object index, but a programmer can provide for one 
>> if it's wanted.
>> 
>> Anyway, garbage collectors need to find all the objects so they can do 
>> their job, so in garbage-collected languages the information must be 
>> available in some manner.
>> 
>> 
>

Received on Monday, 3 December 2018 11:17:32 UTC