RE: idempotency of triple stores

Henry:
I guess what you are saying is a different story (*); if I have two
statements containing the same property, e.g.

ex:productA ex:costs "123"

and

ex:productA ex:costs "140",

then these will of course be represented as two different triples. Even
contradicting statements are no problem at the level of pure RDF, e.x.

ex:tea ex:hasTaste  ex:great
ex:tea ex:hasTase ex:bad

The initial question was to my understanding that whether, if you add two
IDENTICAL statements, there will be two identical triples or not, and I say
that a proper representation of an RDF triple store does not contain
duplicates of the exact same *explicit* triple, if subject, predicate, and
object are exactly the same, as long as everything takes place in the same
RDF "subspace" (e.g. document, model, graph - however you want to call it).

As it was pointed out, some implementations might not meet that requirement,
and I guess this is due two the following problems:

a) A repository might have a hard time spotting identity. Especially when
the object is a literal value, it will be hard to define and detect
identity, because a store will likely just compare the lexical
representations and not the values.

b) When sets of RDF triples that use namespace prefixes are merged, it can
also be difficult to spot identity, unless you store subjects, predicates,
and objects in their full expanded form, which can consume a lot of extra
space.

Also, the question should be separated from the level of ontology languages
and reasoning, since the core question applies also to just a "dumb" RDF
store without any reasoning, I read those just as sets of triples (S,P,O).

Best wishes,
Martin 
 
(*) funny coincidence, I must say :-)


-----Original Message-----
From: semantic-web-request@w3.org [mailto:semantic-web-request@w3.org] On
Behalf Of Henry Story
Sent: Donnerstag, 20. Oktober 2005 20:16
To: Mailing Lists
Cc: semantic-web@w3.org
Subject: Re: idempotency of triple stores


My guess is that that depends on the ontology you are using, as well as the
way you have set up your triples store.

If dc:title were defined as being owl:functional or owl:inverseFunctional,
or if some other constraint existed that had the same effect then adding
duplicate triples would create a contradiction. Your store, or the program
for adding the triples to the store, should take the appropriate action.

I don't think that dc:title has this type of restriction set in the
ontology. So it would not be wrong for the store to add all three.

Good ontologies should in my opinion be monotonic (not sure how indempotency
and monotonicity [1] are related). That is if you add new facts your
database should remain consistent. This means that one often needs to model
the state of things at a time. So if a Person has a height one should not
have properties such as

[ a foaf:Person;
   :height "1m45";
   foaf:mbox "joe@smith.org";
   ...
]

As Joe may grow and so end up having a different height. It would be much
better to have something like

[ a foaf:Person;
   foaf:mbox "joe@smith.org";
   :timeSlice [ :date "Jan 12 1990";
                   :height "1m45 ];
   :timeSlice [ :date "Jan 12 2000";
                   :height "1m90";
   ...
]


Ontologies such as this will be much easier to deal with as they should
reduce the need to delete facts.

Henry Story


[1] http://en.wikipedia.org/wiki/Monotonic_function

On Thu, 20 Oct 2005, Mailing Lists wrote:
>
> Hi,
>
> If I am dumping data into a triple store and my data ends up having 
> duplicate triples how is a triple store supposed to handle the dupes?
>
> For example, if I try to insert these three triples:
>
> <isbn:0802130208>		<dc:title>		<"A Confederacy of 
> Dunces">
> <isbn:0802130208>		<dc:title>		<"A Confederacy of 
> Dunces">
> <isbn:0802130208>		<dc:title>		<"A Confederacy of 
> Dunces">
>
> Will I end up with three triples or one in the triplestore?
>
> Is there a specification for how a triple store is supposed to treat 
> this situation or does each follow its own rule?
>
> Thanks,
> Mark

Received on Thursday, 20 October 2005 18:46:59 UTC