Page History

Implementation Proposal:

The Fedora 4 repository relies heavily on metadata to describe and manage its digital content.  There is a large intersection between the types of data Fedora uses in its implementation to manage data and the PREMIS standard for metadata that supports information necessary in the description of preserved digital objects.  In fact Fedora currently relies on PREMIS to describe content nodes such as the properties premis:hasContentLocaiton and premis:hasSize.

...

It might possible for the #hasEvent to be used as both the object of an rdf:type predicate and the predicate pointing to an objects actual event. Otherwise a fedora ontology predicate could be created for the object of the rdf type.

I think in the PREMIS ontology the premis:Object is the container of premis:Events, and its relationship to the owl:Thing it describes is indicated by http://id.loc.gov/ontologies/premis.html#hasRelatedObject - Benjamin Armintor

2) The PREMIS vocabulary can also be used within the event child objects by creating he child nodes and using the #hasEvent predicate to point to them.  Inside the event nodes PREMIS predicates could be added, at a minimum:
http://id.loc.gov/ontologies/premis.html#hasEventDateTime
http://id.loc.gov/ontologies/premis.html#hasAgent
http://id.loc.gov/ontologies/premis.html#hasEventType
http://id.loc.gov/ontologies/premis.html#hasEventOutcomeInformation

...

The PREMIS service would then subscribe to events with event types representing these methods, to create an PREMIS record reflecting these event types.  The methods which generate these events also have application in the task of implementing a XACML authorization system as policies can be built with finer grained action targets that what is currently possible with modeshape actions. 

PREMIS structure and retrieval

fedora structure:
-resource (object/datastream node)
  -premis (a container node)
    -event1 (hasEventType,hasEventDateTime,hasAgent,hasEventOutcomeInformation)
    -event2 (hasEventType,hasEventDateTime,hasAgent,hasEventOutcomeInformation)
    -event3 (hasEventType,hasEventDateTime,hasAgent,hasEventOutcomeInformation)

triples:
<http://localhost:8080/rest/object> <rdf:type> <http://fedora.info/definitions/v4/rest-api#premisResource> .
<http://localhost:8080/rest/object> <http://id.loc.gov/ontologies/premis.html#hasEvent> <http://localhost:8080/rest/object/premis/event1> .
<http://localhost:8080/rest/object> <http://id.loc.gov/ontologies/premis.html#hasEvent> <http://localhost:8080/rest/object/premis/event2> .
<http://localhost:8080/rest/object> <http://id.loc.gov/ontologies/premis.html#hasEvent> <http://localhost:8080/rest/object/premis/event3> .
<http://localhost:8080/rest/object/premis/event1> <http://id.loc.gov/ontologies/premis.html#hasEventType> "node added" .
<http://localhost:8080/rest/object/premis/event1> <http://id.loc.gov/ontologies/premis.html#hasEventDateTime> "2007-03-01T13:00:00Z" .
<http://localhost:8080/rest/object/premis/event1> <http://id.loc.gov/ontologies/premis.html#hasAgent> "fcrepo4 repository" .
<http://localhost:8080/rest/object/premis/event1> <http://id.loc.gov/ontologies/premis.html#hasEventOutcomeInformation> "node added info" .

retrieval:
1) use the fedora structure of object/datastreams with premis nodes and properties in a service that serializes them into json that can re returned from a restful call.  This might be implemented at the resource level (each object and datastream), or an aggregation (on an object that also pulls in it's datastream PREMIS info)
2) use the triples such that sparql queries can be created to return events and their properties in a flexible way