W3C home > Mailing lists > Public > public-owl-wg@w3.org > June 2008

Re: One comment on RDF mapping [related to ISSUE 67 and ISSUE 81]

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Wed, 11 Jun 2008 16:56:32 +0100
Message-Id: <B2CAEA79-6D50-410F-8C74-EB977EC9D0D4@cs.man.ac.uk>
Cc: public-owl-wg@w3.org
To: Alan Wu <alan.wu@oracle.com>

On 11 Jun 2008, at 16:42, Alan Wu wrote:

> Hi,
> The following was the original question I sent to Boris, Peter, and  
> Bernardo. We have had quite some
> email discussions.
>> The first sentence of 2.1.1: If /ax'/ is translated into a single RDF
>> triple s p o, then the axiom /ax/ generates the following triples
>> instead of triple s p o.
>> I wonder why (s p o) is not generated? I can certainly see the reason
>> for NegativePropertyAssertion.
>>  Generating (s p o) may seem redundant. However, it makes  
>> implementation
>> a lot easier. From a database's perspective, find (s p o) is a simple
>> lookup. Find (_:x rdf:subject s) and (_:x rdf:predicate p) and  
>> (_:x rdf:object o) involves quite a few joins.
> Note that if one has a huge ontology and *tons* of annotated  
> axioms, sifting out those original axioms is going to
> be time consuming.

This presumes a specific and rather suboptimal implementation.  
There's nothing stopping an implementation from generating s p o or,  
indeed, *never* having the explicit subject, predicate, object  
triples (instead they could use a 4 place predicate with a "context"  
slot that indicated whether the triple was reified; many current  
triplestore implementations are, in fact, quad stores).

Or one could keep reified triples in different tables, etc. etc. etc.

I think we shouldn't conflate issues in the serialization with issues  
in the implementation.

It is clear that using reification will stress that part of  
implementations. That is, implementations will have to be a bit more  
clever about it.

Received on Wednesday, 11 June 2008 15:54:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:04 UTC