Comments on history system descriptive note

2.2 Resources

'Bundle' seems to be missing from the object model here.  (See http://dspace.org/technology/system-docs/functional.html#data_model).  Is this because it's missing from the existing history data or some other reason?

The definition of 'Bitstream' seems more appropriate to 'Bundle', e.g. something along the lines of 'Bundle: The set of formatted stream of bits that, when decoded by a compliant piece of software, will provide a representation of the Item.'  Of course most Bundles will consist of just one Bitstream but many won't, for example HTML documents with many pages and PEG images.

2.2.4 Communities

Actually these are collections of Collections.

3 Issues and Recommendations

Throughout section 3, I'd find it much more useful if the examples were shown as RDF graphs instead of or in addition to the almost impenetrable RDF/XML serialisation.

3.1.2 Duplicate Properties

Maybe being an RDF novice I'm picking up on something that's been discussed ad infinitum, but tying two schemas together like this is seems rather dodgy.  What is the scope of that, just the history data?  What if some 'agent' (for want of a better word) has a load of RDF data that includes Harmony and DC data from other sources?  Would the subPropertyOf extend to the other data it has?

3.1.3 Lack of Type Information

I don't understand this enough to be able to comment, but there does seem to be an error in the 'after applying recommendation' snippet (rdf:Collection closed by rdf:Description.)

3.2.3 Usage of Local URIs

Could do with an example?

3.2.4 Formatted Text in Property Values

This seems like an RDF-level issue, i.e. how do you represent stuff that isn't a very simple ASCII or Unicode string as an RDF literal?  Is it possible?


General comments:

One issue I don't see addressed here is repetition of information.  Is each file written by the history system supposed to be a model in it's own right, or is the intended aim that all of the output forms one big model, with information common to the whole model held in one place?  For example, in 3.1.2, whyere would the fact that hasPart in Harmony is a subPropertyOf hasPart in Dublin Core be stored?  In every file or just one place?

A big issue here that doesn't seem to have been picked up (unless it is somehow covered by the namespace issue) is how to give URIs to DSpace objects.  E.g. in the present system a bitstream might be 'http://www.dspace.org/bitstream/1234'.  The '1234' is just a local database primary key which is very probably duplicated at other DSpace sites.  This will have to be changed.  In the case of items, collections, and communities, e.g. 'http://www.dspace.org/bitstream/1271.1/5678', the number on the right (1271.1/5678) is a CNRI Handle, so this should be unique from site to site.  However it might be a good idea to use the Handle properly (i.e. 'hdl:1271.1/5678') instead.

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

Received on Wednesday, 7 May 2003 12:46:26 UTC