Re: Ideas for store for IFP smushing

I had a discussion with Joe Geldart about exactly this thing on friday.

I think smushing is a good idea to integrate data-stores and based on 
IFPs, it should be a good technique.
But I would base it on OWL rules that say something like 
"owl:SameIndividualAs" when IFP's are the same.

sure, the OWL approach would be harder to program as you would have to 
do the evaluation during read access of the database and not write 
access. Smushing on write is easier.

about properties and classes:
you cannot dump all URIs, thats not wise. you will lose properties and 
classes. It is impossible to differentiate between identification URIs 
and vocabulary uris.
so I would suggest not to trash the uris but to add new data to existing 
URIs, when you have a match by IFP (although that may also have easter 
eggs, the most elegant way would be the OWL way)

also, I am in the "religious group" of URI resoluters, thereby i like to 
parse urls to check what server they are hosted on and to query more 
information about the resource by contacting the server (f.e. over 
URIQA). From this view, I do not like the identification of resources by 
IFP.
I like to write URLs on things and give them to people, so that they can 
get curious, and get more information by entering the url somewhere.

cheers
Leo


Es begab sich aber zu der Zeit 06.08.2004 14:01,  da Phil Dawes schrieb:

>Hi RDF Interest,
>
>Have been thinking a lot recently about techniques for smushing IFP
>based data (inc. foaf, doap etc..), and Sandro's uname paper[1] got me
>thinking about the optimisation possibilites of an extra layer of
>indirection.
>
>I'm putting together a prototype store (derived from the design of
>Steve Harris' excellent 3store) that doesnt expose URIs to the user
>except through explicit queries containing (?foo :uname ?uri). This
>disconnection between resource and URI offers some reasonably compact
>strategies for IFP and owl:sameAs smushing (since the resource -> URI
>can be 1:N without duplicating triples). It also provides optimisation
>possibilities for cases where the client isn't interested in URIs, but
>just the structure of the data and its literals. (I've found this to
>be the case when obtaining RDF infromation for e.g. displaying in a
>UI).
>
>Instead of BNodes, I'm using generated internal ids with a limited
>lifespan (remain constant between smushing passes). This is mainly
>because you can't use bnodes for properties, but also because it
>enables a client to efficiently submit multiple queries using the
>short-lived internal URIs for speed.
>
>The downside to this approach is that I can't think of a way to
>efficiently undo a smushing pass, which you'd want to do if e.g. you
>unasserted an IFP.
>
>Has anybody else explored these possibilities? Anything I ought to
>consider?
>
>Cheers,
>
>Phil
>
>[1] http://www.w3.org/2001/12/uname/
>
>  
>

Received on Monday, 9 August 2004 08:26:05 UTC