W3C home > Mailing lists > Public > semantic-web@w3.org > July 2012

Re: Why do we name nodes and not edges?

From: Nathan <nathan@webr3.org>
Date: Sun, 29 Jul 2012 14:09:18 +0100
Message-ID: <501535FE.8000901@webr3.org>
To: David Booth <david@dbooth.org>
CC: Hugh Glaser <hg@ecs.soton.ac.uk>, Michael F Uschold <uschold@gmail.com>, Steve Harris <steve.harris@garlik.com>, Austin William Wright <aaa@bzfx.net>, Melvin Carvalho <melvincarvalho@gmail.com>, Semantic Web <semantic-web@w3.org>
David Booth wrote:
> Another approach (instead of reification, which I personally hate), is
> to use named graphs.  Named graph have to be used differently, but can
> often solve the same use case.
> For RDF stores that store everything as quads anyway, my guess is that
> even if you have only one named graph per triple it would likely involve
> less overhead than reification, but perhaps one or more of the
> developers of such stores can comment on that more authoritatively.

As I understand it, Melvin is looking for a well defined function that 
would allow one to canonicalize a triple (edge) in to a unique URI. Such 
that f(subject, predicate, object) = edge:123234234 .

Reification allows you to name a triple, but it's not in a canonical 
form with a unique name per triple.

In logic we assign symbols to statements all the time (~A & B), but not 
in a well defined way where each unique statement has exactly one 
canonical name.

An interesting question, is whether two identical triples (edges) from 
different documents would share the same canonicalized form, or whether 
the provenance / named graph would need to be part of the 
canonicalization. More of a f(subject, predicate, object, graph) = 
<edge:graph#123wer234d23> where 123wer234d23 is a hash(subject, 
predicate, object).

One use case of for this (from Melvin) would be to apply weights to 
statements: { X :magnitude 10 } where X is a uri which identifies the 
statement { :Bob :trusts :Mary } .


Received on Sunday, 29 July 2012 13:10:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:38 UTC