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

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

From: Henry Story <henry.story@bblfish.net>
Date: Mon, 3 Dec 2018 10:16:22 +0100
Message-Id: <60EA9C39-B20E-4E6B-8DCE-9CFB2A8FECDA@bblfish.net>
Cc: Thomas Passin <tpassin@tompassin.net>, Semantic Web <semantic-web@w3.org>
To: Anthony Moretti <anthony.moretti@gmail.com>

> 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.

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 <mailto: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 09:16:49 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 08:45:57 UTC