DSpace History System: RDF Schema Design

Hi Jason

A couple of comments on the History System RDF Schema Design Document. First
I was very impressed as the document seems very well put together even
though this was an early draft. I liked the section "Functional Changes" in
particular which was clear and well structured.

I have a couple of comments. First in your example on subproperty
inferencing in Section 2.2, I think it would be helpful to have some
clarification i.e. you need to state that DC explicitly defines date as "a
date associated with an event in the life cycle of a resource". When I first
read this section, I found it confusing because I would regard date as a
data type rather than a superproperty. This is because an entity (e.g. a
person) can potentially have many different date properties that do not
share meaning (e.g. birthday, date of birth, wedding anniversary, next
holiday, leaving day, projected retirement date, long service award).
However it does seem more natural to regard these properties as
subproperties of event. So I think the confusion here stems from DC. In
addition, the concept "event" is very noncommittal so unlikely to be of use
when inferencing so in your example even if we read date as event, I think
this is unrealistic as date is too unrefined for this to be practical.
Consider a program designed to automatically close peoples accounts on their
leaving date, that started to close accounts on their holiday date due to
inference. 

So here's a suggestion, although feel free to do further revision:

"For example, the Dublin Core Element Set [cite
http://dublincore.org/documents/dcmi-terms/] defines the date property as "a
date associated with an event in the lifecycle of a resource". This property
can have refinements, or a sub-properties such as created or modified
events. These properties may be further subclassed, and a client that only
understands the first level of refinements can still understand more refined
properties using inference. As long as the simpler client is not permitted
to write a modified property value to a more refined property slot, the two
clients can safely operate on values of these properties."

Alternatively it may be possible to come up with an example using
:isSubEventOf, which is a sub-property of isPartOf in Harmony.

In section 3.2 and 3.3 you adopt the convention of having properties start
with a lower case letter whereas classes start with an upper case letter. It
might be worth mentioning this convention explicitly. Also you don't use the
convention in the text prior to section 3.2, as there are a few instances
where properties start with upper case letters which is confusing.
Unfortunately you have both classes and properties with the same name (e.g.
Created and created). This is perfectly legal, but I think we should try to
avoid it as it is potentially confusing. Perhaps you could consider changing
the name of the Events to something like CreatedEvent to distinguish it from
created?

Another minor point in the schema definition, it's now considered good
practice to use xml:lang to declare the language of text e.g. comments or
labels. Then in the example RDF-XML serialisation, your URNs don't look
particularly unique. Sorry this is a pain but I think that they need to be
at least locally unique, so you need to generate some reasonable random
numbers?

hope this helps, best regards

Dr Mark H. Butler
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

Received on Thursday, 29 May 2003 11:36:50 UTC