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

It think it's the same as the discussion around Addresses, it just depends
from type to type what constitutes a key. With regards to doing it in
RDF/OWL I have no idea, I just know the way I'd try and approach it if I
was coding it in OO. Could be wrong, I really have no idea. I just thought
the temporal logic aspect was worth talking about because I've tried to
think about n-ary relations before.

Anthony

On Tue, Dec 4, 2018 at 5:42 PM Patrick J Hayes <phayes@ihmc.us> wrote:

> How can you ever know that the particular argumets given to the n-ary
> relation are enough to constitute a key?  And if you do know it, how can
> you state it so as to validate the inference? I don’t think (?) it can be
> stated in, for example, OWL. You would need at least FOL with identity, way
> beyond RDF expressivity.
>
> Pat
>
> On Dec 4, 2018, at 7:37 PM, Anthony Moretti <anthony.moretti@gmail.com>
> wrote:
>
> To do with the n-ary relations part I've thought about this before, I'm
> not sure if I'm right. Because RDF doesn't have temporal logic you have to
> assume all triples are valid in the present (to do otherwise you would need
> valid-time metadata). The same goes for n-ary relations that don't have
> "start time" or "end time" properties. I'd argue that those have to be part
> of the key for any event, so if you have multiple blank nodes *without* those
> properties those blank nodes are actually describing a *type* of event,
> and it _could_ be valid to conclude those blank nodes are equal, the chosen
> keys would depend upon the type of type.
>
> Type:
>
>     {
>         id: _:PatHittingWallEvent,
>         type: _:PatHittingWallEventType,
>         agent: _:Pat,
>         target: _:Wall,
>         device: _:Hammer
>     }
>
> Instances:
>
>     {
>         id: _:patHittingWallEvent1,
>         type: _:PatHittingWallEvent,
>         startTime: 12:00:00,
>         endTime : 12:00:01
>     },
>     {
>         id: _:patHittingWallEvent2,
>         type: _:PatHittingWallEvent,
>         startTime: 12:00:02,
>         endTime : 12:00:03
>     },
>     {
>         id: _:patHittingWallEvent3,
>         type: _:PatHittingWallEvent,
>         startTime: 12:00:04,
>         endTime : 12:00:05
>     }
>
> There wouldn't be the problem of concluding these blank nodes are equal
> because the times are different.
>
> Anthony
>
>
> On Tue, Dec 4, 2018 at 4:36 PM Patrick J Hayes <phayes@ihmc.us> wrote:
>
>>
>>
>> > On Dec 4, 2018, at 2:30 PM, David Booth <david@dbooth.org> wrote:
>> >
>> > On 12/3/18 8:29 AM, Henry Story wrote:
>> > > . . .  So what are the advantages of blank nodes
>> > > pragmatically? They make a description local to the graph
>> > > in which they appear and this locality is maintained
>> > > across merges. The meaning of URI referenced resources can
>> > > be completed by external information of course but the
>> > > description ensures that no further links need to be taken
>> > > into account when understanding the bnode's meaning. So it
>> > > looks like it's ideal for things that need to be entirely
>> > > defined by description.
>>
>> OR that cannot be *defined* at all, which is closer to the original idea.
>> Henry, why would you assume that everything that can be mentioned, can also
>> be /defined/?
>> >
>> > Interesting point!   That means that blank nodes enjoy a
>> > form of closed world assumption (CWA),
>>
>> No. That is exactly the kind of mistake that one gets into by being too
>> loose with words like ‘define’.
>>
>> > in that there *cannot*
>> > be any other triples asserted (directly) about a blank node,
>> > other than the ones already in the document/graph/dataset
>> > at hand.  (Inference could add some though.)
>>
>> Yes, it certainly could, if one has access to something like OWL.
>> >
>> > Of course, if we are dealing with implicit blank nodes -- the ones
>> generated by [] or () notation in Turtle -- then it's even more obvious
>> that the only property connections to/from that blank node are the ones
>> provided right there.
>>
>> Inference can add extra trioles to those also. Suppose for example you
>> know that the property rdf:rest is funcitonal and you know that x:A
>> rdf:rest _:x ., and someone tells you that
>>
>> x:A rdf:rest _:y .
>> _:y x:Q x:C .
>>
>> then you know know that  _:x owl:sameAs _:y ., and hence that _:x x:Q x:C
>> .
>>
>> Now, someone might argue that such cases are vanishingly rare, or even
>> that they shouldn’t be allowed or encouraged, but that would be a different
>> argument.
>>
>> >
>> > This brings me to an interesting question.  To rephrase, the "identity"
>> of a blank node object is determined entirely by the identities of its
>> connected nodes, because it is guaranteed to not have any other connections.
>>
>> It isn't, if we allow inferences.
>>
>> >  Therefore, a blank node labeling algorithm (or standard Skolemization
>> algorithm) only needs to take into account the subgraph of that blank
>> node's tightly connected neighbors.  By "tightly connected" I mean the
>> subgraph that is connected only through consecutive blank nodes.  (I think
>> this may be slightly different from the Concise Bounded Description (CBD),
>> because the CBD starts only with the *subject* of a triple.)
>> > https://www.w3.org/Submission/CBD/
>> >
>> > Aiden (or someone else), is this correct?  If so, this would be very
>> beneficial, because the labeling algorithm could then be guaranteed to
>> generate the *same* label (or Skolem URI) for the blank nodes in that
>> subgraph, regardless of any larger graph in which that subgraph appears.
>> This is very pertinent to n-ary relations, because it means that blank
>> nodes for the same n-ary relation, appearing in different RDF graphs, could
>> be automatically given the *same* label (or Skolem URI) -- even without
>> knowing a key for that object.
>>
>> That would be a wildly invalid conclusion. The coding of an n-ary atomic
>> sentence into binary RDF basically says that an ‘event’ (or a ‘fact’, or
>> ‘situation’, or…)  exists which represents the fact of the relation holding
>> between the participants. So my hitting a wall with a hammer (a three-place
>> relation) might be encoded as a bnode of type hitting with an agent being
>> me and an object being the wall and the means being the hammer. But there
>> might be a whole lot of hits of that wall with that hammer by me. You can’t
>> infer that the many bnodes which encode various assertions of this kind are
>> all the same single entity with a single global identifier: for one thing,
>> that would imply that I only hit the wall once.
>>
>> >  Aiden, is this what such canonicalization algorithms already do?
>>
>> I REALLY hope they don’t.
>>
>> Pat
>>
>>
>> >
>> > David Booth
>> >
>> >
>>
>>
>>
>>
>