RE: idempotency of triple stores

Hi Henry,

 

ISO 15926-compliant  ontologies, being set up for lifecycle information,
work with "temporal parts" of individuals that exist in space-time. Any
temporal part of such an individual is a placeholder for information about
that individual. When the information turns invalid, the temporal part ends
its existence. Your example of a rapidly growing Joe Smith would be a
candidate.

 

We *never* throw away anything, in order not to lose lifecycle information.

 

Whenwe have to deal with realtime information that is rapidly changing (e.g.
a measurement of a flow rate) we would get far too many triples. Then we can
use a blob representing a time series (e.g. during an Operations work
shift). This blob can be structured to the HDF5 format [1], and be analyzed
later.

 

Regards,

Hans

 

[1] http://hdf.ncsa.uiuc.edu/HDF5/

 

_______________________ 

Hans Teijgeler

ISO 15926 specialist

www.InfowebML.ws

hans.teijgeler@quicknet.nl

phone +31-72-509 2005      

 

-----Original Message-----
From: semantic-web-request@w3.org [mailto:semantic-web-request@w3.org] On
Behalf Of Henry Story
Sent: Thursday, October 20, 2005 8:16 PM
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