The EAC ontology (see http://www.jeromedl.org/eac/1.1/ for more information) is used at the bottom layer in JeromeDL. It is used to describe access controls to a digital objects repository.
Modern digital library systems not only store bibliographic metadata but also an electronic representation of the content itself. Depending on its type,content typically follows some structure, e.g. we can decompose a book into chapters and provide individual descriptions for each chapter with information about relations between them. Including structural concepts in ontologies and using these concepts in metadata descriptions provides a universal layer for metadata and content retrieval. The structure description can be extended with new concepts, without violating the integrity of existing data. The application of ontologies for structural descriptions enables uniform access to structural and bibliographical information, and delivers new search and discovery possibilities, as described in (221)
An alphabetical index of EAC terms, by class (categories or types) and by property:
Classes:
Properties:
EAC ontology introduces the following classes and properties.
The action concept defines basic actions identified within certain applications. In the case of REST services these would be the basic HTTP methods: access (GET), modification (POST), creation (PUT), and removal (DELETE). Each Action is computed as a conjunction or sum (depending on the value of the is conjunction property) of Condition s.
Defines rules for accessing resources or invoking GET services.
FORMER: http://www.jeromedl.org/structure#ActionAccess
Defines rules for creating resources or invoking PUT services.
FORMER: http://www.jeromedl.org/structure#ActionCreate
Defines rules for modifying resources or invoking POST services.
FORMER: http://www.jeromedl.org/structure#ActionModify
Defines rules for deleting resources or invoking DELETE services.
FORMER: http://www.jeromedl.org/structure#ActionRemove
Defined in the FOAF ontology (http://xmlns.com/foaf/0.1/Agent)
The condition concept defines an atomic policy condition, which aggregates a number of Rule s. The result of computing the policy condition is a conjunction of results of atomic rules. EAC Condition can be organized in hierarchical structures. It allows users to define abstract policies which are conjunction of other policies.
Identifies type of a condition.
License is the most important concept in the EAC model. It aggregates positive (al lows for performing certain actions) and negative (denies for per- forming certain actions) conditions for each type of action. A single license can be assigned to many Licensed Entities. It is validated by the EAC engine (see Sec. 5) against conditions defined in the licenses for the actions to be performed on the given entity. The license can define whether the negative (deny first = true) or positive (deny first = false) constraints should be computed first.
Agent/person who obtained the license.
Agent/person who provided the license.
Licensed Entity is an abstract concept of a resource (Licensed Resource) or a service (Licensed Service ) to which a license can be applied. The Licensed Resources, following the aggregation capabilities of semantic digital libraries, support passing the license down to the sub-components of the given resource. The way in which the license is applied to sub-components, and in which it is computed for the resources and its sub-components, is defined by the Propagation State of the license.
Represents all resources which can have licenses attached to them
Represents services which can have a license attached to them. It is preferable that we use REST services for that matter.
Propagation State Identify how the license is applied to the Licensed Resources, and how it propagates to sub-components of the given resource. Possible states include: applying to the give resource only (Resource Only), to the resource and only direct sub-components (With Children), or to the resource and any sub-components (With Descendants); it is also possible to apply the license to the direct (Only Children) or all (Only Descendants) sub-components, but not the the resource itself.
Rule defines an atomic rule, which computed against give resource and within certain context returns boolean value, e.g., IP network address range, a part of a social network, maximum usage count.
An event that is passed from the Triggering Source (e.g. Licensed Entity) through Triggering Bus (communication channel) and affects the Triggering Listener (e.g., License).
An object that can accept Triggering Event.
Source that is capable of emitting Triggering Events.
Binds positive rules for accessing, modifying, creating or removing resources (or services).
FORMER: http://www.jeromedl.org/structure#allowAction
To whom the license belongs (Licensee)
Binds negative rules for accessing, modifying, creating or removing resources (or services).
FORMER: http://www.jeromedl.org/structure#denyAction
Defines the position at which the EAC Condition is hold in the hierarchy of conditions tree (in fact it tells the ordering number between peer EAC conditions)
Binds atomic specifications of rules to action access control definitions.
FORMER: http://www.jeromedl.org/structure#hasProtectionDefinition
Identifies types of conditions (recognized and supported by plugins of EAC module)
FORMER: http://www.jeromedl.org/structure#drmType
Binds sub-resource in aggregation view to the license inherited from the upper resource
Binds licensed entity to the license
Defines how the license specification is propagated through the aggregation of resources (book → chapters → pages)
FORMER: http://www.jeromedl.org/structure#licensePropagation
Defines one of many rules that create a condition.
Determines if the EAC condition is currently active or not
Tells whether the Action specification should fulfill all conditions or just some
Defines if the negative conditions should be evaluated before the positive conditions
FORMER: http://www.jeromedl.org/structure#isDenyFirst
By whom the licenses was issued (Licensor)
FORMER: http://www.jeromedl.org/structure#isDenyFirst
(deprecated property) Used to indicate relations between real chapters (as handled in JeromeDL prior-2.1) and license entities of chapters (as handled in JeromeDL 2.1+). It probably become absolute once we bNodes from the aggregation model in JeromeDL 3.0