W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2001

Re: rdfapi question

From: Chris Cera <cera@drexel.edu>
Date: Tue, 8 May 2001 11:45:33 -0400
To: "Balon, Corey" <cbalon@grci.com>
Cc: "'Chris Cera'" <cera@drexel.edu>, www-rdf-interest@w3.org
Message-ID: <20010508114533.F19453@cera.ws>
* Balon, Corey <cbalon@grci.com> [010508 15:13]:
> You're never guarenteed to even have to the superclass
> declared before the subclass in the rdf. So, even if the
> triples come out in order, you'll still have this problem

I would design my ontology with this in mind, thus to avoid the
search problem entirely.  The problem is that the interface for
Model doesn't require the Enumeration of triplets returned by
elements () to be in any particular order, I'm wondering if 
somebody knows of something that can create (or implemented
already) this in order as exactly defined in the rdfs/daml file 
you're reading.

The 2nd of your methods involve searching through some container 
of class objects to retrieve objects that need to be have data
members set b/c we have received new information about an object
we already created.  I suppose I could insert some sort of key 
value for the classes so then a heap or better data structure 
could be created, thus to guarantee O (log n) for the search 
operation.  Any suggestions on the best data structure and/or 

This is for a CSCW tool which must send strings over the network 
and be in as close to realtime as possible for synchronized 
graphics display.  I'm planning on requiring this extra 
restriction on the ontology to eliminate the time for the search.

> 1) do two passes. on pass one, create all the objects and keep
> 	a mapping from the object's URI to the object. In pass two
> 	do the relationships between the objects (looking up the objects
> 	in the map).

I suppose that hashing on that would be the least expensive 
method for this approach..  This would be probably be the most
robust since the rdf file wouldn't require the ordering
restriction (the way its supposed to be).  Thanks alot, any 
better suggestions would be greatly appreciated.
Received on Tuesday, 8 May 2001 11:46:05 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:36 UTC