- From: Tansley, Robert <robert.tansley@hp.com>
- Date: Fri, 16 May 2003 13:37:12 -0700
- To: " (www-rdf-dspace@w3.org)" <www-rdf-dspace@w3.org>
I think there's a big missing piece from the history discussion and model. It's to do with representing different states of Items (and other objects.) To illustrate it, consider a super-simple example of a DSpace Item, hdl:1271.1/5678, which has its dc:title fixed by an administrator. Now, the history data should NOT contain (as I believe it currently does) this triple: hdl:1271.1/5678 ----- dc:title -----> My Super Researck Paper because, later, when the administrator corrects the title, the following triple will be deposited: hdl:1271.1/5678 ----- dc:title -----> My Super Research Paper This wouldn't do, because when the data is collected into a unified store for query, there would be no way of telling with which state each dc:title is associated. (It's by virtue of the statements being in separate files that one can tell right now.) We need a way of representing the item in a particular state (i.e. at a particular moment in time.) I'm not sure which part of the Harmony ABC model would best be used to do this; the examples in http://www.metadata.net/harmony/JODI_Final.pdf don't quite fit. One possible way to consider is, in the context of the Harmony ABC model, to let a DSpace Item be a 'Work'. 'Manifestations' are individual states of that DSpace Item. Then, part of the data in the history system when the administrator corrects the DSpace Item would look like this: hdl:1271.1/5678 ---- harmony:hasRealization ----> XXXXX XXXXX ----- dc:title -----> My Super Researck Paper hdl:1271.1/5678 ---- harmony:hasRealization ----> YYYYY YYYYY ----- dc:title -----> My Super Research Paper Now the relevant ABC bits and bobs can relate XXXXX and YYYYY, explaining how we started with XXXXX and arrived at YYYYY. (Maybe there's a more appropriate part of the model than Work/Manifestation but this demonstrates what is missing from the current model.) Other gnarly questions are: * Do individual Bitstreams and Bundles have separate states, or are they married to Item states? For example, if I change what is in a Bundle, does that bundle get it's own states and transitions modelled, or do we just deal with those events at the Item level? * If a new Item is added to a Collection, does that mean the Collection has changed and is now in a different state? Ditto Community/Collection, ditto Community/Collection/Item. Gnarliest of gnarly things, if I change a Bitstream that's in a Bundle that's in an Item that's in a Collection that's in a Community, does that mean the Item's changed? Does that Item changing mean the Collection's changed? Does that Collection changing then mean the Community's changed? I think we really need some example walkthroughs of typical events, with graphs along the lines of Appendices C-F of http://www.metadata.net/harmony/JODI_Final.pdf. The way the work is currently being discussed feels to me like we're examining individual trees but have no idea what the forest looks like. Robert Tansley / Hewlett-Packard Laboratories / (+1) 617 551 7624
Received on Friday, 16 May 2003 16:38:32 UTC