RE: Representing distinct item states

> >I really don't think, given the purpose and use of the 
> History system, 
> >that it needs to be optimised for query.  Unlike the rest of 
> DSpace, it's a write-lots, query-not-so-often subsystem.  The 
> important thing is that it has the right data, and has it 
> securely.  We can always build/use tools that can do the 
> indexing, inferring and optimising and point them at the 
> History data later.
> >
> I thought that Mick's goal for the integration of DSpace and Haystack 
> was in part to allow users to browse along the dimensionality of the 
> history system as easily (and thus as quickly) as they browse the 
> current fixed hierarchy. 

My take would be that it's the client's responsibility to take the model/schema/ontology and instance data and do whatever is necessary to present it and make it performant to the user.  Different tasks may have very different requirements; I don't think that model/schema/ontology designers should have to deal with the overhead of worrying about performance.

> At least one vector within the history system is likely to be very 
> common -- the list of recent changes.   It isn't too hard to imagine 
> navigating to a subregion of the database and then following 
> a history 
> vector which should be constrained to the histories that apply to the 
> current navigation context either.  I think in the end that 
> you'll find 
> most queries of the history system will be more common than 
> you suppose 
> here.

In my opinion, if we're thinking about how to model temporal data, intermingle that with semi- or unstructured, multi-schema data, attempting to make it performant at the same time is WAY too big to bite off in one go.  We need to reduce the dimensionality of the problem so each can be tackled as separately as possible.  Hence my METS AIP suggestion, which would greatly simplify one aspect of the History system problem.

 Robert Tansley / Hewlett-Packard Laboratories / (+1) 617 551 7624

Received on Monday, 19 May 2003 14:42:44 UTC