Your opinion on the following would be very much appreciated. If you want to leave comments you have to request access. We will grant you access as soon as possible.

How would you prefer locally defined identifierTypes to be managed?

In the ontology, the premis:identifier property has an open range, so you can manage your local identifiers in 2 possible ways:

1. You decide that the range is an instance of premis:Identifier, with a premis:identifierType and a premis:identifierValue:

<event1> premisowl:identifier <event1-ID>.

<event1-ID> rdf:type premis:Identifier;

                  premis:identifierType "someUniversityIdentifierType";

                  premis:identifierValue "12345678".

Pros: You just have to maintain your identifierTypes as character strings.

Cons: Verbosity: You need 4 triples to declare an Identifier.

OR

     2.  You decide that the range is a character string, and you declare the particular identifierType as a property:

 You declare your local identifier Types in your local repository:

<http://university.edu/local#someIdentifierType> rdfs:subPropertyOf premis:identifier.

Then you can describe you assets with a single triple.

<event1> <http://university.edu/local#someIdentifierType> "12345678".

Pros: Conciseness - When making assertions about your digital assets, you only need one triple.

Cons: You need to create and maintain your own RDF controlled vocabulary. That requires slightly more energy and, arguably, architecture if you want to actually define those local classes and properties for others to see.

     3. In the end, do you prefer a single solution or both? Both is more flexible for implementors, but it can complexify interoperability afterwards.

How would you prefer to manage eventTypes?

We want to reuse the controlled vocabulary for preservation events at id.loc.gov is http://id.loc.gov/vocabulary/preservationEvents.rdf

For the moment, eventType is a property linking an Event to a skos:concept.

Every member of the premis controlled vocabulary being a skos concept. 

Thus, a "creation" event that occurred on 2011-07-10 would be declared as

<event1> a premis:Event;

              premis:eventType <http://id.loc.gov/vocabulary/preservationEvents/creation>;

              premis:eventDateTime "2011-07-10".

The problem is that this pre-existing id.loc.gov vocabulary declares each eventType as a property relating an event to a dateTime.

According to this, we should state <event1> <http://id.loc.gov/vocabulary/preservationEvents/creation> "2011-07-10", that seems to strongly deviate from the original data dictionary and is strange from a modelling standpoint (2011-07-10 being a date, not a creation).

There would be the following possibilities:

1. Declaring all particular http://id.loc.gov/vocabulary/preservationEvents as dataType properties AND classes at the same time, which is weird but keeps up with legacy data.
2. Declaring  http://id.loc.gov/vocabulary/preservationEvents only as classes, removing the "dataTypeProperty" type. This is more satisfactory but breaks backwards compatibility with existing uses.
3. Declaring a new vocabulary like http://id.loc.gov/vocabulary/preservationEvent with all particular eventTypes as classes. This keeps both pros of 1. and 2. with the risk of end-users confusing the 2 vocabularies.

What choice would you have?

Sticking to the original Data Dictionary VS having a simple RDF modelling

For the moment, our decision was to be as close to the Data Dictionary as possible.

• Some properties really have common semantics: XYZValue, XYZName, XYZNote... Would you prefer to model a single property for all of these same semantic units? For instance, a single premis:name for each premis:name property?
• Do you think the ontology is okay this way or would you prefer it more "flat" / concise? The Data Dictionary is meant to be abstract, but some semantic containers do really fill some kind of XML-bucket function.
• For example objectCharacteristics looks like a "bucket" to store all the semantic units which give us information on the object characteristics. But we don't necessarily need this intermediary level in RDF.

Would you prefer verbs for properties?

For the moment we merely have lower case properties. But we can use verbs (for instance premis:objectCharacteristics premis:hasSoftware premis:Software)