Re: Deleting subgraphs via SPARQL (illegal?)

On 6/28/05, Reto Bachmann-Gmür <reto@gmuer.ch> wrote:

> I didn't know that the deleting triples is supposed to be illegal, but I
> have sympathies towards this idea. At least I think that it may be a
> good design requirement for ontologies not to require deletion of
> statements when the world changes. Your example with reified statement
> that may considered true depending on the trust is a good example:
> you'll never want to delete one of those triples, but maybe add triples
> to express that you started distrusting the guy who said the statement
> at a certain point in time.

I don't think there's really an issue of legality, if you delete some
triples then you just have a diffferent graph, as you do when you add
triples. In fact deleting triples may be safer, you're not going to be
introducing any inconsistencies...an empty graph is a sae graph ;-)
 
> In my experience developing application it is often a resource (like an
> Article) which has to be removed rather than distinct statements. What
> should be deleted with the "article", just its properties? its CBD? the
> CBD without statements with a subject that is the object of another
> statement in the model? I don't think that any of these approaches is a
> good solution in all cases.

Yep, I'm now running into those kind of issues (with RSS aggregation)
that presumably you've already been through with Knobot. It's not
obvious what is the best solution.

> Forbidding deletions is probably a too radical approach (after all, I
> want some institutions to delete my address completely), however we can
> try to collect triples that we will never have to delete. The key is to
> look for "brute facts" (not for finding them, just to get closer). The
> RDFization of  "xy will have a speech from 2005-07-02 10:00 till 12:00"
> is much less robust than "xy has accepted the invitation to a speech
> from 2005-07-02 10:00 till 12:00 on 2005-06-28", the second assertion
> allows the first to be a reasonable guess till we add the triples to say
> "xy has canceled his speech scheduled for 2005-07-02 10:00 on
> 2005-06-29".

That makes sense. I suppose the more stores there are (globally) then
the less need there will be to keep lower-relevance statements.
Storage is cheap, but keeping them in the foreground will presumably
cost in access time.

Giovanni, I don't suppose your RDFGrowth algorithm might be tweakable
to allow you to efficiently maintain accessible archives? So you'd
maybe have immediate stuff  in-memory, longer term in a triplestore as
usual, but then have linkage to a massive/very long term store in the
background. Then don't delete, archive.

Cheers,
Danny.

-- 

http://dannyayers.com

Received on Wednesday, 29 June 2005 07:23:56 UTC