Re: lack of support for claims regarding Concise Bounded Descriptions (see MSGs)

>I'm looking at [1], and I am puzzled by the definition of an MSG.
>
>The MSG of a statement that has a blank node as a subject or object is
>defined in terms of the MSGs of all statements that use that blank node as
>a subject or object.  This seems to me to be a self-referential definition.
>
>  
>
isnt it a standard declarative definition?  by using the word "set" of 
triple duplicates are removed so you dont get in a loop really, if 
that's what you meant. We might add "statements not included so far" 
somewhere if that makes it more clear or more correct. We'll look into it.

It might be easier to understand in other terms however: an MSG of a 
statement is the "blank node closure graph" including that statement.

>>CBDs are the union of all the Minimum Self contained Graphs, "involving" 
>>a starting URI. 
>>    
>>
>
>I don't believe that this is the case.  Consider the RDF graph
>
>	ex:a ex:r ex:c .
>
>The CBD of ex:c for this graph is the empty graph, but the MSG of ex:c is
>the entire graph.
>  
>
Patric has several definitions of CBD.. some are simmetric wrt subject 
and object some are not.
Our is simmetric as there is, clearly, no reason for using an asymmetric 
one given that there is no reason why ontologies should use active 
rather than passive terms.
So the union of the msgs involving a node should be identical to patric 
symmetric cbd .. it might be different ifhe also adds reificatiions of 
ground triples which are not the original one should check that but it 
could be reconcilied (if he changes his definition ;-)  )

>> 
>>rebuild it correctly, you cant do it in any fine granularity or in any 
>>coarser without duplicating transfers of information (or loosing some). 
>>    
>>
>
>You need to have a particular model of information flow for this to work
>out right, though.  
>
>  
>
well given that a statement belongs to 1 and only 1 msg and that you acn 
extract i the model is straightforward, you extract it, you send it (its 
a perfectly valid self contained RDF) and ot ther other end it can be 
marged right away. Iterate and you have transferred the whole graph 
without ever sending statements twice and with minimum bits.
In our P2P system we actually transfer "RDFN" which is similar to CBD 
basically a peer asks another "what do you know about URI x" and this 
will provide all the MSGs involving X. This causes some duplicate 
triples sometimes. Say you first ask a peer about the song "like a 
virgin" , well you'll get a msg which says that madonna sang it.. then 
you might ask about madonna and you get the same MSG back.  But that's 
really not a bug, its a normal behaviour, its clear that it makes ense 
to have that MSG since it does in fact involve the 2 uris. This makeit 
that peers dont all have to know the same thing, one might be interested 
justin madonna another just in that song .. the'll have some overlapping 
information but not all of course.

>>MSgs are 
>>guaranteed not to interfere with other MSGs so they can be safely 
>>inserted and removed, MSGs can be uniquely named leading to a few 
>>intersting properties (i.e. we're working on efficent syncinc of 
>>RDFGraphs, results due soon).
>>    
>>
>
>I don't understand what "interfere" means here.
>
>  
>
Inserting an MSG into a triplestore will not alter any other existing 
MSG. this is fairly obvious from the definition, but really nice if you 
think of it. The key point is that bnodes are not addressable from the 
outside and we're considering just the case where an "update" is a piece 
of rdf coming from the outside ..in that case you will not alter the 
content or structure of exisitng MSGs in your DB. which in our case is 
what guarantees that digital signatures will be shipped along with the 
data they refer to and will not break no matter wher ethey are inserted 
into (which triplestore) and which other information is added at a later 
time.

On the other hand, interesting behavours where people change the 
structure of MSGs remotely are possible .. for example in DBin a local 
client might retract or modify an msg from its DB if it receives another 
MSG that says so by pointing at the one to retract in the terms of the 
hash of its the canonical form. This way a "group administrator" or the 
original author of the msg can state "I say please remove that one and 
put this one instead" remotly , and , since the hash is really a digital 
signature, in a way that can be trusted.

Sorry if this gets a bit involved in what seems to be out application 
specific behaviours, it is however the case that these are properties 
spawning from RDF (basically from the definitions of bnodes) which  
gives them more applicability that just DBin.. for example  see the 
"revokation without quotation" issue.

Giovanni

Received on Sunday, 5 June 2005 23:15:03 UTC