- From: Reto Bachmann-Gmür <reto@gmuer.ch>
- Date: Tue, 28 Jun 2005 21:39:21 +0200
- To: Giovanni Tummarello <giovanni@wup.it>
- Cc: semantic-web@w3.org, "Thomas B. Passin" <tpassin@comcast.net>
Am Donnerstag, den 23.06.2005, 11:08 +0200 schrieb Giovanni Tummarello: > "Statement" is nicely generic, it doesnt force you to actually have > the > triple stated. What prevents you from using a subclass of statement > which does in fact state that the triple.. is stated. > That's what we do in the rdf context toolkit [1] where we attach a > signature with a subclass of reification which basically says "this > guy > said this, up to your trust policy to decide if its in the model or > not" > perfectly legal as nobody forces you to merge all you receive to your > model. > ... > > One question i do have is.. is it really illegal to delete triples in > rdf? should'd a RDF model reflect a real world interpretation? if the > world changes, should the model should change as well? I believe i was > talking to Seaborne about this. I am puzzled :-) i too gave the > assumption that monotonicity meant shouldt delete stuff but they seemed > to disagree based on this issue. Clarifications anyone? :-) 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. 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. 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". reto
Received on Tuesday, 28 June 2005 19:39:27 UTC