Re: Reification - whats best practice?

Hi Thomas, hi all, just a  "use case",  "me too"  here. We're about to 
integrate a security model in DBin (www.dbin.org) a P2P semantic web 
tool idieally geared at the masses :-) (but not right now since there is 
yet no security). In DBin there is a complete smushing of annotations 
that people make about the URI they decide to share inside "knowledge 
growth groups" (think IRC like groups) so we'll end up with graphs which 
are  filled with triples each one needing to have a reference to its 
specific author (to be later used to filter out what doesnt reach our 
"trust level" according to user definable rules)
Named graphs in this use case are .. not of much use! We want all the 
triples to be in the same graph anyway.

about signign statements.. well we dont really sign statements but 
subgraphs which are made of a given statement and if this has blank 
nodes of all those which have the blank nodes as a subject or predicate 
and recursivly so until ground nodes (URIs. or litterals) are found. We 
call these MSG minimum self contained graph, since in a P2P environment, 
its the minimum amount of rdf you can send to another peer. If you were 
to send "dangling" blank nodes.. it wouldn make much sense and you 
couldnt at a later time refer to the bnode you originally sent (unless a 
IFP is given but that's just a case).
There are a few interesting properties of the MSGs,  given any triple in 
a msg you can uniquely find the msg itself. (it can be shown, see the 
paper on out homepage). This says that to attach a digital signature to 
a msg you only reyfy a single triple.
The API for doing alll this is ready by the way, and we include an 
inplementation of Carrol's graph c14n procedure.  and a nice api that 
given a URI it will tell you all the MSG about it, which signatures 
there are and allow you to add/remove them. release of this part of the 
code should happen soon ,

Sooo :-) all this to say that, expecially since a large amount of MSGs 
wil lbe made of a.. triple only.. we expect a large amount of 
reifications to be needed  and we're therefore very interested in some 
more concise way to handle it. Of course we expect the underlaying db to 
handle it in a more efficent way internally than the full RDF bloating 
but we're still shipping RDFgraphs around (during the p2p exchanges) and 
t would make a big difference.   I have been reading with great interest 
the idea of using subclassed properties as a reification means. You 
mention it would "break owl in some part" i might have missed a better 
explanation, why would it be so?

> 1) An ability to attach arbitrary meta data to subgraphs, and 
> especially down to the granularity of individual triples.  This is 
> needed in practical diagramming and data store work.  For example, to 
> keep an history of all changes to a triple (their dates, the user who 
> changed them, etc.), to specify drawing symbols, and line placement 
> and characteristics, and so on and so on on.  Metis and DOORS are two 
> examples of applications that allow such meta data.  Metis, in fact, 
> is practically RDF except for this feature.
>
> Put another way, there is no reason that triples (or relationsips, at 
> least) should not be treated as first class objects, the same as 
> subjects.  It's true that most logic formulations keep predicates as 
> classes or types rather than individuals, but it's equally true that 
> practical work requires them to in fact be individuals.
>

Received on Wednesday, 8 September 2004 15:52:10 UTC