Re: Reifying triples as unique URIs

Max Völkel wrote:
> Hi, I was looking for a neat way to address statements.
>
> Version 1)
> ---------
> Ok, I know there is reification, but that's quite expensive:
> Asking  in  SPARQL  for  information  about (a,b,c) is also not really
> concise.
>   
That's because the working group explicitly refused to standardize ( 
despite its obvious usefulness and the minimum effort to do so, imo) .  
Anyway you can quickly write yourself a preprocessor or ask your DB 
vendor about it.

> like
> (x,a,b,c)
> (x,e,f,g)
> (x,h,i,j)
> (y,l,m,n)
>
> all  quads  (x,*,*,*)  form  a  named  graph "x" with threee triples -
> great! I want to keep this. So, do I need fivelets?
>
>   
I am not sure about what you mean (my silly?) but usually anything can 
be solved by bloating the named graph space (the number of graphs you use).


> Version 3)
> ---------
> Unique Relations
>
> This  is  a  new idea, that I haven't seen discussed anywhere - that's
> why  I post this email. The idea is: In some way, the relation between
> two things is unique. So we represent
> (a,b,c)
> as (a,x,c), (x rdfs:subPropertyOf b).
>
>   
Some time ago when we were considering the model to use in DBin to track 
provenence of triple sand yet not use named graphs or brew it yourself 
solutions we considered this model as well.
If i recall correctly, the main argument was that it didnt allow the 
context node to be a bnode which we really wanted on the other hand. 
Properties must be URI.
We wanted to use Bnode (if needed) to be sure that a context would not 
be altered when adding more triples to the model. This is a requirement 
for a number of situations. Take a look at [1], digital signatures 
insider RDF Graphs.  if we didnt use a blank node then adding a triple 
involving the same URI used for the context node (be this a property or 
a reification node) then by adding a new graph with that URI the digital 
signature would turn out to be invalid.
Then, in general using subproperties seems a strange idea.. in DBin we 
separate ontological bits (those written in RDF/OWL) from "data".. this 
approach tends to mix the two things in a sense.

Alternative solutions

1)  Use MSGs. MSGs have natural IDs, you can quote parts of graphs 
simply by naming MSGs. This is nice for a number of reason, very 
powerful but not supported directly by sparql. Would require some extra 
infrastructure. We're now in the process of working with the Sesame guys 
to consider supporting this at some lower level. MSG theory is by the 
way directly off the RDF semantics and are useful for a number of reason 
among which avoiding duplicate triple structures when merging graphs 
with bnodes.

2) This is funky : :-) In case where RDF is a dump of a relational DB  
use 3 extra properties named SameSubjectPredicateStatement 
SamePredicateObjectStatement SameSubjectObjectStatement.  

Example
    a knows b,c,d,e....
Reify the first triple only then attach b c d e to the statement node 
with the SameSubjectPradicateStatement predicate :-) . you get a group  
of statements, all connected to a single reification node for the cost 
of 1 triple per reification instead of (4+1) * statement (the 1 is to 
group the reification nodes together)
might even be sparqllable .. havent thought deep of it. ;-)

 i hope it helps a bit
Ciao ciao
Giovanni

[1] Signing individual fragments of an RDF graph
Giovanni Tummarello, Christian Morbidoni, Paolo Puliti, Francesco 
Piazza  
http://semedia.deit.univpm.it/submissions/www2005/WWW2005_signignRDF.pdf

Received on Monday, 7 August 2006 16:14:20 UTC