> We can definitely model approval, review, and editing as
> actions/events in Harmony ABC. I had assumed that these
> properties are maintained after the events themselves for
> audit purposes. I do not think it is useful or descriptive
> to have a "workflowStep" property with literal values,
> because we end up with the same issue that we have now with
> other non-URI identifiers. It may be better to have a model
> of the workflow such that each step is a resource that could
> be referenced by such a property. The open question is
> whether these properties are part of the action that makes
> the workflow continue or whether these properties are part of
> the item moving through the workflow.
I would think the properties were part of the action rather than part of the item moving through (though the Dublin Core provenance field contains this information).
> According to "DCMI Metadata Terms" [1], "accessioned" and
> "author" are not Dublin Core properties. I have tried to
> represent these properties as sub-properties of sensible
> Dublin Core properties. Alternatively, if there are Dublin
> Core properties that represent the meanings of these
> properties, we could represent them as Dublin Core properties
> (e.g. - dateAccepted and creator).
>
> Because the DC registry appears to support only the DC
> namespace, I would recommend that we do find DC properties
> that represent these. Alternatively, History could provide a
> reverse map from qualified name to the appropriate namespace.
Oops, you're right. I didn't realise the Library Application Profile used qualifiers that are outside of these DCMI terms. It's a slightly tricky one... we could 'roll up' to the unqualified terms (contributor instead of contributor.author, and date instead of date.accessioned) though this does lose some important information. Simply defining our own terms might perhaps mean that the data is less accessible to clients that only understand DC and not the History schema/ontology; however, I find it hard to believe that a client that doesn't understand the History schema/ontology is going to be able to make any use at all of the data in the History system, so in this case it's probably OK to define our own properties.
Perhaps we could use 'subPropertyOf' here? e.g. have a 'dsh:author' property that's a subPropertyOf dcmi:contributor?
Robert Tansley / Hewlett-Packard Laboratories / (+1) 617 551 7624