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
S3B Tagging Ontology (see http://s3b.corrib.org/tagging/ for more information) extends the basic concepts introduces by the Tom Gruber's TagOntology (150) with support for annotating fragments of information items using typed tags (object, setting, agent, action).
An alphabetical index of S3B Tagging terms, by class (concepts) and by property (relationships, attributes):
Classes:
Properties:
An alphabetical index of S3B Tagging terms, by class (categories or types) and by property. All the terms are hyperlinked to their detailed description for quick reference.
ROI of circular shape
Defines a range within the tagged document (pages, ROI, time-tag)
Group of numbers (tagging:hasXCoordinate, tagging:hasYCoordinate) used to indicate the position of a point.
Represents documents which are being annotated
Indicates a range in the multimedia stream
Region/Range of interest on the photo, movie
ROI of polygonal shape
ROI of rectangle shape
Represents an agent (person or service) that provided the particular tagging
Represents the tagging action, i.e., binds annotations and their author to the tagged document
An abstract concept defining the annotation concept (tag, keyword, topic, etc)
Specifies tag/term of the type action, e.g., eating
Specifies tag/term of the type agent, e.g., man
Points to an ordered collection (rdf:Seq) with coordinates; each resource (of type tagging:Coordinate) in this collection will have tagging:hasXCoordinate and tagging:hasYCoordinate.
Binds the tagging to the region (part of) the multimedia resource
Indicates relation to an internal resource or its region
Indicates when the range in the multimedia stream ends
Indicates when the range in the multimedia stream starts
The height of the rectangle ROI (should be percentage value)
Specifies tag/term of the type object, e.g., banana
In the circle ROI this property specifies the radius of the circle indicating the ROI (should be used as a percentage value of the size of the photo, NOTE: since there two dimensions to specify percentage by - this ontology defines the radius as a percentage value of the width of the photo/object)
Specifies tag/term of the type setting, e.g., beach
Indicates the tagging operation related to given document
See also: sioc:topic. Binds Terms to the tagging concept.
When the tagging was issued
The width of the rectangle ROI (should be percentage value)
The X coordinate of the rectangle ROI (should be percentage value); indicates horizontal coordinate the upper-left corner of the rectangle ROI or a center of the circle ROI
The Y coordinate of the rectangle ROI (should be percentage value); indicates vertical coordinate the upper-left corner of the rectangle ROI or a center of the circle ROI
Indicates whether this tagging is publicly available (following the model in del.icio.us)
Reference to other document (might be just URI), usually from outside of the system
(from DC metadata) Indicates who has provided the tagging
(from DC metadata) longer description of the resource/tagging
(from DC metadata) the title of the element
(from DC Terms metadata) when the object was created
(from SIOC ontology) person who provided the annotation/post/etc
(from SIOC ontology) what resource the annotation is related to
(from SIOC ontology) See also: hasTerm
SSCF Ontology (see http://s3b.corrib.org/sscf/0.2/ for more information) describes objects and properties that are used by Social Semantic Collaborative Filtering.
SSCF is a personal knowledge management system. User builds a personal hierarchy of directories (personal taxonomy) and fills it with a links to interesting resources (web bookmarks, MultiBeeBrowse bookmarks). Users can share the gathered knowledge with others by importing others' directories. System provides also an import feature - one can import resources stored in different bookmarking system (like del.icio.us)
An alphabetical index of SSCF Ontology terms, by class (concepts) and by property (relationships, attributes):
Classes:
Properties:
An alphabetical index of SSCF Ontology terms, by class (categories or types) and by property. All the terms are hyperlinked to their detailed description for quick reference.
Special kind of Resource. Resource that holds other resources creates tree structure.
Holds the evaluation information
Resource which is a link to the search in MultiBeeBrowse.
Special kind of WebResource. URL which is a link to bookmark and is imported from a bookmarking source.
SSCF resource. It is generic bookmark. All resources that does not have specified type and should be treated as a bookmark should be instance of this class.
Special kind of Directory. Resource that holds the information about tagger account. This is also Directory that may contain other resources (with isIn property).
A word or phrase that is recognizable by people and computers
SSCF ontology uses Post concept from SIOC ontology to capture community contributed textual annotations.
Special kind of Resource. Resource which is a link to the page in a Web, URL.
Holds the resource access policy, e.g., a FOAFRealm realm rule:
F[mailto:foo@bar.com]1.4
Links resource with its annotation.
Points to Person that create the Resource
Indicates that resource follows other resource, opposite to isIn.
Informs if there is a tag (Term) assigned to the Directory
Used by Annotation module to export data. Represents the following properties: rdf:type, sscf:annotates, sscf:isEvaluatedWith.
The sioc:has_creator property links a Post to its author's User account. Thus, we can follow the link from the post to the creator and locate the other posts by the same User.
The community can be seen as a network of posts with users linked to each post, and there is also a network of other posts created by a given user stemming from there. We can use this information in community sites to locate more contributions by the given author.
Used by Annotation module to export data. Represents jeromedl:publishedAt (in case the using with JeromeDL instance) or sscf:isIn (for relation between main and subdirectory)
Represents the connections between sioc:Posts (one annotation can be an answer to the other). Also used to export data.
Used by Annotation module to export data. Represents the properties of sscf:Resource, sscf:Evaluation or sioc:Post
Shows if the Directory was imported. Shows the location from which the Directory was imported.
Defines in which domain is the given directory. (Currently deprecated)
Shows by which object the given Resource was annotated.
Points to the super directory. This is the mean to create tree structure.
- Indicates that the Directory is suggested to be placed in another Directory.
Holds the date of creation of the Resource
Indicates if the Directory should no be placed again in some other Directory as a suggested Directory.
Indicates how many times the Resource was opened or clicked.
Holds the value of the evaluation.
The FOAFRealm system takes advantage of social networks and FOAF profiles in user profile management systems. However, the FOAF standard must be enriched with new concepts and properties that are described in this document. The enriched version is called FOAFRealm.
An alphabetical index of FOAFRealm terms, by class (categories or types) and by property ( see http://www.foafrealm.org/xfoaf/0.1/ for more information):
Classes:
Properties:
FOAFRealm introduces the following classes and properties.
Represents a domain of interest linked to the SSCF Directory instances
Represents an resource within the web application
Defines valid FOAFRealm ACL entry (*, ISAFRIENDOF, F[login@domain]distance {,|.}trust)
Defines which resources are being annotated by this one
Describes some biography, resume or credential of the person
Indicates if the user profile is stored locally or if is distributed
Defines the annotations that this annotations follows/responds to in the conversation
Reifies the foaf:knows statement to define the trust level between people
Indicates if the user required to hide his email address during the FOAF export
Local signature (done with SHA1SUM and RSA keys) on the foaf:knows and foaf:knows reifications
Describes person nationality
The property stores SHA1 sum of the password that with the email address stands for credentials of the person login in with FOAFRealm enabled service
Reifies the foaf:knows statement to define the trust level between people
Name of the relationship between two Persons; it identifies more precisely the nature of the relationship
private RSA key - not exportable from home server, pass-phrase locked
public RSA key - exportable to and stored by other servers, together with foaf:seeAlso information
Used to identify logged user
Applications can make use of it to handle
caching in distributed environments
Defines the value given to in this evaluation
Classes and properties from other ontologies can be used together with FOAFRealm. During the FOAFRealm ontology design process some external classes and properties were identified that are suitable for reuse. Such concepts are not included inside FOAFRealm but are use directly together with terms from FOAFRealm to describe the information about on-line community.
This sections list the main external classes and properties that can be used with FOAFRealm in a meaningful way. This list is not and can not be exhaustive because many RDF ontologies can be used together.
The goal of MarcOnt bibliographic ontology (see http://www.marcont.org/ontology/2.1/ for more information) is to provide a uniform bibliographic description format. It should capture concepts from existing formats such as BibTEX, Dublin Core, MARC21. As the process of development of such an ontology is complicated it should involve a community of domain experts sharing their knowledge and experience, together building community ontology with tools such as MarcOnt Portal96.
The ontology It is to be used in JeromeDL (see Chapter 7) as a format capturing bibliographic descriptions of the resources. The ontology is also being used as a mediation format in MarcOnt Mediation Services97. With use of MarcOnt ontology one can transform bibliographic descriptions of the resources between supported formats (BibTEX, Dublin Core, MARC21) and MarcOnt.
When talking about ontologies, classes are often identified with objects in the real world. Their names often reflect this approach (e.g. Person class in the FOAF ontology represents a human being). Because of that creation of list of classes in the ontology and their hierarchy seems to be straightforward. The main problem occurs when one should build a model of particular domain of interest on multiple models existing in this domain. This is a case when building a bibliographic ontology. Such an ontology should be built on the base of existing metadata standards (e.g. BibTEX, DublinCore etc.). This implies the complicated process of achieving consensus on the ontology.
An alphabetical index of MarcOnt terms, by class (concepts) and by property (relationships, attributes), and instances are given below. All the terms are hyperlinked to their detailed description for quick reference.
Classes:
Properties:
Instances:
An alphabetical index of MarcOnt terms, by class (categories or types) and by property:
Types of media available to access a resource.
Represents the concept of a scientific publication (usually in a journal).
Represents the concept of a book.
One of the types of resources - a small information book, a booklet.
Represent a concept of cluster - sub-unit of an institute.
Represents collection of resources.
Represents the concept of a scientific event - a conference.
This class represents the range of the "coverage" annotation property from Dublin Core.
Poster session at a workshop or a conference.
Class represents all types of events related to publication process.
Represents a concept of a faculty - subunit of a university.
One of the types of resources - part of a Book (e.g., a chapter in the Manuscript)
One of the types of resources - part of larger collection
One of the types of resources - an article in conference, workshop or proceedings
Represents the concept of Institute.
Represent the journal concept.
Represents a concept of a Laboratory, a sub-unit of a cluster.
A very short talk. Usually lasts no longer than 5 minutes.
One of the types of resources - a manual or a use guide.
One of the types of resources - Master's thesis document.
This class should be used to represent a general type of a meeting involving a number of agents.
One of the types of resources which does not belong to any other category: Miscellaneous.
Represent the concept of on organization.
One of the types of resources - PhD Thesis document.
Representation of a poster session at a given event (e.g., conference).
Class represents all types of presentations that can be given during an event.
One of the types of resources - proceedings of conference or workshop
Represents an abstract concept of publication medium - can be conference proceedings, book, website/social medium, journalÂ
Base class for all bibliographical resources.
Provides information related to the review process.
Short talk refers to a talk that last approximately 15 minutes and is given during an event.
Represents an electronic publication medium with a community of users build around it, etc. Facebook
Talk represents all types of talks and presentations different from Demo session, Poster session and Tutorial, that can be given during an event.
One of the types of resources - technical report.
This class represents tutorial given at a conference (or in some cases in other circumstances).
This class represents the concept of a university.
One of the types of resources - a resource that has not been published.
Represents a generic Internet-based publication medium
Represents the scientific event, less prominent and more focused than a conference.
Abstract of the resource. This property is equivalent to the bibtex:hasAbstract property.
Usually the address of the publisher or other type of institution. For small publishers, on the other hand, you can help the reader by giving the complete address.
Affiliation of a given person.
Attaches information about human author of the resource or the collection of resources.
Begin date of the copyright period.
Used to identify table of contents (TOC)
An entity responsible for making contributions to the content of the resource but not the author.
The extent or the scope of the content of the given publication medium.
This property can be used to describe the creator of a given resource or of the given collection of resources. It can be either a person, a group or an organization.
Describes appropriate type for the resource according to the Dublin Core Metadata Initiative dictionary of types.
Property refers to a Digital Object Identifier assigned to a given resource.
Date related to the entity. In case of Events, date of the occurrence.
Description of an event contains information that is to be viewable for the user (in contrast to dc:description property)
Describes the domain of interest appropriate for the resource.
The edition of a book, e.g., Second. This should be an ordinal, and should have the first letter capitalized, as shown here; the standard styles convert to lower case when necessary.
Defines the editor of a given resource or collection of resources.
End date of copyright period.
Property used to describe the creator of the resource or the collection of resources.
Assigns an identifier in the form of ISBN.
Represents the ISSN number assigned to a given resource.
This property represents the unique identifier of the resource.
Journal where the article was published.
Keyword related to the resource.
The month in which the work was published or, for an unpublished work, in which it was written. You should use the standard three-letter abbreviation. Equivalent to bibtex:hasMonth property.
Any additional information that can help the reader.
The number of a journal, magazine, technical report, or of a work in a series. An issue of a journal or magazine is usually identified by its volume and number; the organization that issues a technical report usually gives it a number; and sometimes books are given numbers in a named series.
Refers to the order of resources in Jerome Digital Library. Each resource is given a number to allow control over their order.
The organization that is involved in organizing an event or publishing given resource.
Describes an original publication medium of the resource. The medium is of a type marcont: AccessMedium.
Number of pages of the resource or chapter.
The starting page of the given document (article) in the collection (e.g., in-proceedings)
The starting page of the given document (article) in the collection (e.g., in-proceedings)
Describes publisher of a given resource.
Represents relation between a resource and an event.
Binds one (or more) reviews to the information object.
When the review of this library resource has been submitted.
Indicates who (or what process) has reviewed this library resource.
Comment given by the reviewer in the review.
University / school where the work was created/published
The name of a series or set of books. When citing an entire book, the the title field gives its title and an optional series field gives the name of a series or multi-volume set in which the book is published.
Used as citation property, equivalent to dc: source property.
Sponsor of the Resource or the event.
The title of the work. This property is used to describe titles both of a given resource and an event.
Topic of the resource.
URI of the DCMI type or the resource.
The volume of a journal or multi-volume book.
The year of publication or, for an unpublished work, the year it was written. Generally it should consist of four numerals, such as 1984.
How something strange has been published. The first word should be capitalized.
Represents a is-part-of relation between elements that belong to a collection or between collections.
This property denotes that this agent is a peer of (in the scientific community meaning) another personÂ
Relates given resource to an event where it was presented.
Defines publication medium where given resource was published  (Delete) rdfs:label : published in
Represents electronic media representations (CD-ROM and other)
International coverage of a resource.
Represents Internet accessible resources.
Local coverage of the resource.
National coverage of the resource.
Medium used to access resources physically available (e.g., printout)
The structure ontology (see http://www.jeromedl.org/ontology/2.1/ for more information) is used at the bottom layer (classic services and metadata) of JeromeDL architecture (see Sec. 7.2). It is used to handle typical tasks required from a digital objects repository, i.e., it keeps track of the physical representation of resources, their structure and provenance. The structure ontology provides means for a flexible and extendable electronic representation of objects. Such flexibility is especially significant in expressing relations to other resources.
Modern digital library systems not only store the bibliographic metadata but also the electronic representation of the content itself. Depending on its type, the 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. It supports extending the structure description 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 (212,197).
An alphabetical index of JeromeDL terms, by class (categories or types) and by property.
Classes:
Properties:
JeromeDL structure ontology introduces the following classes and properties:
This is an information object which has a binary representation, such as JPG, PDF, etc. NOTE: meta-information extracted from the resource (e.g., EXIF) should be directly bound to this resource, not through some additional properties (e.g., hasExif), unless the ontology related to this binary resource does not support such direct binding.
Is a special type of jeromedl:Part information object for expressing chapter information.
This is a virtual information object, which is computed out of other resources (disseminator).
This concept binds any kind of annotations to the information object.
A collection created dynamically based on the provided specification.
The special type of media resources, i.e., all image resources (JPG, PNG).
The most abstract type of a resource in the library (NOTE: this concept supersedes jdl1:Book)
The special type of jeromedl:Part, which references the multimedia content.
It is a generic binary type, the distinctive feature is its physical size and the scaling ability.
Represents a single page in a chapter; usually used to capture a scanned page of an antique book.
This is an information object that is a part of another information object.
Represents the proper library resource (book, article, chapter, page).
Defines types of special Information Objects, i.e., Resources; these are the most high level information objects presented to the user.
The aggregation service that can deliver a bunch of information objects in one go.
Defines a list of individuals which cover the submission workflow status.
Specifies number of resources that are used as a source for computing the new resource.
Indicates the attachment of an information object.
Defines type of the resource; used in the main classification scheme in JeromeDL
The ordering number of the collection in the tree of collections (previously http://www.jeromedl.org/structure#collectionOrder)
Literal/string representation of the specification of the collection (previously http://www.jeromedl.org/structure#collectionSpecification)
binds predefined type of collection to dynamic collection.
Used to bind multipurpose context to an information object
Indicates who owns copyrights for given information object
Defines a binary resource (an image) that represents the cover of the information object; also used as a thumbnail of media resource
Points to the most current version of the information object (IMPORTANT: we suggest that either all information objects points to their current versions - even the current ones, or only the non-current ones)
A textual description on the information object
Size of the binary file related to this resource
Defines parameter for invocation
MIME type of the binary resource
Some resources (antique book chapter, PDF, ...) can have information about number of pages (physical size of the resource), compare to marcont:hasNumberOfPages (see Appendix G) representing the actual size of the content of the resource
Indicates the logical page in the resource (it can have binary resources like PNG, JPG and computed resources [disseminators] like DjVu)
An abstract property to indicate that one information object contains another as its part
Points from an information object to aggregation service - e.g., we can point from chapter to a set of pages in one go
Used to indicate the position of the statement on the list
Points to the previous version (IMPORTANT: in case a version is removed, we will not be changing numbers, but we should change the linking)
Binds binary resource or computed resource to the part resource
Smaller representation of the file (e.g., SWF optimized for mobile access)
Defines the specification of a collection; can be a string literal with a structure processable by the dynamic collections module.
Indicates the current submission status of the information object. NOTE: The submission status can refer to the submission process of an article, or to the internal submission workflow in the digital library
When the information object was uploaded
Comment explaining what has changed in this version
A person who created this version
Defines date when this version of the information object was created
A unique number of the version of the information object
Defines the REST service which should be invoked to compute the result
Indicates whether the information object has been peer reviewed to check the correctness of the content
Defines if the information object is a preprint
Indicates should the media object be scaled to fit the content
Defines if collection contains items from sub-collection (previously
http://www.jeromedl.org/structure#sizeWithSubCollections)
Defines if the collection is build as a union of specifications (previously
http://www.jeromedl.org/structure#isUnion)
The person who uploaded the given information object.
Defines if the collection is visible to the end user (previously jdl1:isVisible)
Specifies where a library resource was originally published
This appendix presents example of questionnaires (see Sec. 8.7) that were used during the evaluation (see Chapter 8) to gather users opinion, measure satisfaction and collect users answers in the question-answering tasks (see Sec. 8.2.3). Since participants using DSpace were asked to fill in slightly different questionnaires than those using JeromeDL we present both sets of questionnaires.
This appendix presents additional and more detailed results gathered during the evaluation (see Chapter 8).
This section presents six tables with the details on user satisfaction metrics, gathered with the questionnaires during the evaluation. Table D.1 presents comparison of opinions of JeromeDL and DSpace users on various features implemented by both digital libraries. Since these tables deliver only more detailed view on results presented in Chapter 8 we do not describe them in details.
| Evaluation task | ease of understanding | ease of execution | intuitive- ness | σ | P |
| JeromeDL register | 27.46 ( σ=25.01) | 25.08 ( σ=22.47) | 17.54 ( σ=24.42) | 23.95 | |
| DSpace register | 32.69 ( σ=18.76) | 29.77 ( σ=20.71) | 22.31 ( σ=24.71) | 28.89 | |
| Δregistering σ |
-16.00% | -15.76% | -21.38% | -17.12% | 0.555 |
| JeromeDL adv.search | 33.15 ( σ=19.29) | 15.46 ( σ=29.53) | 11.15 ( σ=28.99) | 21.81 | |
| DSpace adv.search | 32.62 ( σ=17.44) | 17.46 ( σ=28.37) | 13.69 ( σ=33.02) | 22.88 | |
| Δadv.search σ |
1.65% | -11.45% | -18.54% | -4.66% | 0.980 |
| JeromeDL search | 24.38 ( σ=24.65) | 19.23 ( σ=23.54) | 16.46 ( σ=23.91) | 20.65 | |
| DSpace search | 31.08 ( σ=19.03) | 21.08 ( σ=24.16) | 13.85 ( σ=29.39) | 23.3 | |
| Δsearch σ |
-21.53% | -8.76% | 18.89% | -11.37% | 0.837 |
| JeromeDL bookmark | 32.00 ( σ=20.23) | 20.46 ( σ=19.82) | 20.31 ( σ=28.04) | 25.36 | |
| DSpace bookmark | 19.85 ( σ=20.8) | -3.08 ( σ=34.79) | -7.23 ( σ=32.74) | 5.56 | |
| Δbookmarking σ |
61.24% | -765.00% | -380.85% | 356.13% | 0.029 |
| JeromeDL task 1 | 24.38 ( σ=19.76) | 10.77 ( σ=31.18) | 7.15 ( σ=28.83) | 15.57 | |
| DSpace task 1 | 28.62 ( σ=24.43) | 17.08 ( σ=22.74) | 17.85 ( σ=20.55) | 22.24 | |
| Δtask.1 σ |
-14.78% | -36.94% | -59.91% | -29.99% | 0.228 |
| Evaluation task | ease | ease | intuitiveness | σ | |
| of understanding | of execution | P | |||
| JeromeDL task 2 | 34.85 ( σ=16.55) | 24.77 ( σ=22.54) | 25.08 ( σ=21.85) | 29.18 | |
| DSpace task 2 | 11.00 ( σ=33.88) | 1.00 ( σ=36.2) | 3.00 ( σ=26.24) | 5.86 | |
| Δtask.2 σ |
216.78% | 2,376.92% | 735.90% | 398.12% | 0.029 |
| JeromeDL task 3 | 34.00 ( σ=19.08) | 25.23 ( σ=22.9) | 23.08 ( σ=22.01) | 28.37 | |
| DSpace task 3 | 10.38 ( σ=22.78) | 18.15 ( σ=23.83) | 11.46 ( σ=23.79) | 12.91 | |
| Δtask.3 σ |
227.41% | 38.98% | 101.34% | 119.74% | 0.040 |
Table D.3 presents details of users satisfaction related to search and browsing mechanisms implemented by JeromeDL and DSpace systems.
| search task | ease of use | simplicity | intuitiveness | interestingness | attractiveness | usefulness |
| JeromeDL (1) | 17.85 σ=22.06 | 17.46 σ=21.21 | 11.69 σ=20.1 | 17.31 σ=23.86 | 14.23 σ=21.89 | 20.77 σ=26.19 |
| DSpace (1) | 28.85 σ=19.81 | 16.15 σ=20.32 | 15.85 σ=18.52 | -6.31 σ=17.61 | -11.46 σ=20.18 | 9.38 σ=17.97 |
| Δtask.1 σ [%] |
-38.13% | 8.10% | -26.21% | -374.39% | -224.16% | 121.31% |
| JeromeDL (2) | 27.46 σ=19.58 | 21.77 σ=18.22 | 20.08 σ=21.5 | 17.92 σ=17.34 | 14.54 σ=21.08 | 21.77 σ=22.92 |
| DSpace (2) | 10.08 σ=28.01 | 6.38 σ=28.22 | -0.85 σ=23.6 | -14.08 σ=17.1 | -16.92 σ=17.07 | 4.08 σ=24.62 |
| Δtask.2 σ [%] |
172.52% | 240.96% | -2,472.73% | -227.32% | -185.91% | 433.96% |
| JeromeDL (3) | 28.62 σ=15.71 | 23.46 σ=19.77 | 15.31 σ=21.44 | 22.38 σ=22.61 | 14.46 σ=23.13 | 24.00 σ=20.47 |
| DSpace (3) | 23.69 σ=25.75 | 15.85 σ=24.67 | 9.00 σ=25.64 | -10.46 σ=17.75 | -11.46 σ=17.9 | 4.62 σ=21.94 |
| Δtask.3 σ [%] |
20.78% | 48.06% | 70.09% | -313.97% | -226.17% | 420.00% |
Table D.4 compare satisfaction of JeromeDL related to semantic, social and recommendation features offered by the system.
| Feature | ease of use | simplicity | intuitiveness | interestingness | attractiveness | usefulness | σ |
| NLQ | 7.85 σ=33.25 | 11.08 σ=26.54 | 8.69 σ=29.19 | 24.92 σ=27.26 | 12.31 σ=27.6 | 5.77 σ=27.6 | 9.8 |
| TTM | 4.54 σ=24.48 | 9.38 σ=20.75 | 0.62 σ=23.36 | 12.54 σ=19.51 | 3.85 σ=20.76 | 1.92 σ=24.23 | 4.65 |
| Exhibit | 9.38 σ=26.02 | 12.92 σ=17.38 | 5.23 σ=23.13 | 8.77 σ=21.7 | 10.08 σ=15.72 | 12.38 σ=22.55 | 10.04 |
| MBB | -6.38 σ=16.73 | -2.85 σ=9.52 | -3.23 σ=20.24 | 15.15 σ=20.16 | 13.54 σ=16.25 | 12.08 σ=16.29 | 2.8 |
| SSCF | 18.77 σ=28.69 | 16.31 σ=20.03 | 17.38 σ=22.13 | 19.54 σ=17.73 | 14.54 σ=19.46 | 18.46 σ=19.34 | 17.76 |
| Collaborative Browse | 6.92 σ=23.35 | 10.31 σ=14.11 | 10.23 σ=10.58 | 15.15 σ=17.38 | 8.77 σ=18.04 | 12.54 σ=15.81 | 10.28 |
| Blog | 14.92 σ=13.78 | 13.31 σ=12.65 | 13.00 σ=16.57 | 10.69 σ=14.07 | 9.77 σ=16.16 | 14.46 σ=18.39 | 13.44 |
| Ranking | 14.69 σ=23.16 | 13.85 σ=20.38 | 10.69 σ=21.46 | 8.46 σ=12.38 | 7.23 σ=14.17 | 13.62 σ=15.84 | 12.47 |
| Recommend (Resource) | 18.54 σ=21.77 | 21.77 σ=15.3 | 18.85 σ=19.74 | 20.08 σ=17.28 | 13.08 σ=18.45 | 20.62 σ=15.64 | 19.32 |
| Recommend (SSCF) | 20.85 σ=19.54 | 16.31 σ=21.43 | 10.23 σ=19.22 | 15.00 σ=18.56 | 10.92 σ=20.82 | 16.15 σ=17.26 | 15.83 |
Table D.5 compares users overall satisfaction measured before and after the evaluation.
| ease of use | simplicity | intuitiveness | interestingness | attractiveness | usefulness | ||
| JeromeDL pre | 13.46 ( σ=23.8) | 8.54 ( σ=19.03) | 8.15 ( σ=21.83) | 11.54 ( σ=19.8) | 14.54 ( σ=21.52) | 24.15 ( σ=17.19) | |
| JeromeDL post | 18.38 ( σ=22.52) | 14.38 ( σ=18.28) | 6.62 ( σ=24.71) | 24.00 ( σ=18.77) | 14.85 ( σ=21.38) | 22.62 ( σ=19.87) | |
| DSpace pre | 11.92 ( σ=24.36) | 7.54 ( σ=18.43) | 5.15 ( σ=22.02) | -11.46 ( σ=22.73) | -8.38 ( σ=24.26) | 4.00 ( σ=19.7) | |
| DSpace post | 16.69 ( σ=23.51) | 5.92 ( σ=21.5) | 6.77 ( σ=26.21) | -12.85 ( σ=26.57) | -14.85 ( σ=24.06) | 9.92 ( σ=24.2) | |
| Δpre σ [%] |
12.90 | 13.27 | 58.21 | 200.67 | 273.39 | 503.85 | |
| Δpost σ [%] |
10.14 | 142.86 | -2.27 | 286.83 | 200.00 | 127.91 | |
Table D.6 compares overall satisfaction of JeromeDL users from using semantic and social features.
| Enhancement type | ease of use | ease of understanding | ease of execution | simplicity | intuitiveness |
| Semantic | 4.54 σ=21.61 | 2.85 σ=21.38 | 4.46 σ=24.81 | 5.85 σ=17.58 | 1.08 σ=22.27 |
| Social | 25.62 σ=16.01 | 23.92 σ=12.61 | 15.23 σ=19.46 | 10.31 σ=19.73 | 11.46 σ=24.21 |
| Enhancement type | interestingness | attractiveness | usefulness | σ | |
| Semantic | 25.38 σ=18.18 | 12.77 σ=21.99 | 21.31 σ=25.21 | 8.65 | |
| Social | 26.77 σ=19.36 | 22.85 σ=23.45 | 29.77 σ=17.05 | 21.27 |
Finally, Table D.7 compares satisfaction of JeromeDL and DSpace users during the memory task.
| ease of understanding | ease of execution | intuitiveness | σ | |
| JeromeDL | 29.11 ( σ=18.95) | 2.00 ( σ=27.11) | 21.11 ( σ=16.13) | 19.08 |
| DSpace | 10.89 ( σ=23.90) | -17.22 ( σ=30.89) | -1.00 ( σ=24.90) | -0.54 |
| σ | 167.35% | 111.61% | 2,211.11% | 3,635.37% |
After the evaluation we have asked JeromeDL users to select up to three (3) features which they liked, did not liked, found useful, and found useless (see Fig. D.1).
Most of the JeromeDL users liked the simple search and bookmarking feature; only a few less liked SSCF (collaborative filtering), natural language queries (NLQ), TTM, and resource recommendations. Other features were not so highly rated, and some of them, e.g., Exhibit and MBB, were actually disliked by many participants. Surprisingly equally many participants did not like NLQ, TTM, and advanced search. This can be caused by the complexity of the latter two, and limited set of queries supported by NLQ during the evaluation (only those that come with the default JeromeDL distribution).
From the perspective of usability of features implemented in JeromeDL, the search and bookmarking (including SSCF) were the most favorable. TTM, MBB, NLQ, and Exhibit were found pretty useless. In our opinion, it was mainly caused by the complexity of these solutions compared to the tasks users were asked to perform, i.e., answer three questions.
For the purpose of the evaluation presented in Chapter 8, we have recorded nine tutorial videos (screencasts) presenting key features of JeromeDL.
These tutorial videos were published on two movies sharing sites: http://blip.tv/ and http://www.vimeo.com/. On the blip.tv site a dedicated channel has been created to feature these and future JeromeDL tutorial videos: http://jeromedl.blip.tv/. Similar channel has been also created on the vimeo.com service: http://vimeo.com/channels/54414.
The complete set of JeromeDL tutorial videos consists of the following screencasts:
Additionally, a short tutorial on JeromeDL has been publish to
http://www.slideshare.net/skruk/jeromedl-tutorial. It provides some more details about JeromeDL, with pointers to the tutorial videos listed above.
This appendix presents scores which were assigned to articles from the reference database (RefDB, see Table A.1) and other articles (see Table A.2) cited by the participants of the evaluation (see Chapter 8). The scores were assigned based on how well each article answered given questions; we used the Score(ref, q) function (see Eq. 8.2) defined in Chapter 8.
| Article | Q1 | Q2 | Q3 | Q4 | Q5 | Q6 | Q7 |
| Morahan-Martin and Schumacher (2003) | 0 | 0 | 1 | 0 | 0 | 2 | 0 |
| Metzger et al. (2003a) | 2 | 2 | 0 | 0 | 2 | 0 | 0 |
| Wathen and Burkell (2002) | 2 | 2 | 0 | 0 | 2 | 0 | 0 |
| Amiel and Sargent (2004) | 0 | 0 | 2 | 0 | 0 | 2 | 0 |
| Hills and Argyle (2003) | 0 | 0 | 2 | 0 | 0 | 2 | 0 |
| Liu (2004) | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
| Landers and Lounsbury (2006) | 0 | 0 | 2 | 0 | 0 | 2 | 0 |
| Leung (2003) | 0 | 0 | 0 | 1 | 0 | 0 | 1 |
| Klein et al. (2003) | 0 | 0 | 0 | 2 | 0 | 0 | 0 |
| Flanagin and Metzger (2001) | 2 | 2 | 0 | 0 | 2 | 0 | 0 |
| Hebert and Vorauer (2003) | 0 | 0 | 0 | 2 | 0 | 0 | 0 |
| Sanders et al. (2000) | 0 | 0 | 0 | 2 | 0 | 1 | 0 |
| Amichai-Hamburger (2002) | 0 | 0 | 2 | 0 | 0 | 2 | 0 |
| Bierhoff and Vornefeld (2004) | 0 | 0 | 0 | 1 | 1 | 0 | 0 |
| McKenna and Green (2002) | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
| Article | Q1 | Q2 | Q3 | Q4 | Q5 | Q6 | Q7 |
| Hamburger et al. (2004) | 0 | 0 | 2 | 0 | 0 | 2 | 0 |
| Swickert et al. (2002) | 0 | 0 | 2 | 0 | 0 | 2 | 0 |
| Jackson et al. (2001) | 0 | 0 | 2 | 0 | 0 | 2 | 0 |
| Nithya and Julius (2007) | 0 | 0 | 2 | 0 | 0 | 2 | 0 |
| Tidwell and Walther (2002) | 0 | 0 | 0 | 2 | 0 | 0 | 0 |
| Anolli et al. (2005) | 0 | 0 | 2 | 0 | 0 | 2 | 0 |
| Burgoon et al. (2000) | 2 | 2 | 0 | 0 | 1 | 0 | 0 |
| McKenna and Bargh (2000) | 0 | 0 | 1 | 0 | 0 | 1 | 0 |
| Kaye and Johnson (2004) | 1 | 1 | 0 | 0 | 1 | 0 | 0 |
| Metzger et al. (2003b) | 2 | 2 | 0 | 0 | 2 | 0 | 0 |
| Hamburger and Ben-Artzi (2000) | 0 | 0 | 0 | 2 | 0 | 0 | 0 |
| Kiousis (2001) | 1 | 1 | 0 | 0 | 2 | 0 | 0 |
| Flanagin and Metzger (2000) | 2 | 2 | 0 | 0 | 2 | 0 | 0 |
| Schrodt and Turman (2005) | 0 | 0 | 0 | 0 | 0 | 0 | 2 |
| Tseng and Fogg (1999) | 1 | 1 | 0 | 0 | 0 | 0 | 0 |
| Metzger et al. (2003c) | 1 | 1 | 0 | 0 | 1 | 0 | 0 |
| Kraut et al. (2002) | 0 | 0 | 2 | 0 | 0 | 2 | 0 |
| Bonebrake (2002) | 0 | 0 | 2 | 0 | 0 | 2 | 0 |
| Stanton and Stanton (2001) | 0 | 0 | 1 | 0 | 0 | 2 | 0 |
| Fogg and Tseng (1999) | 0 | 2 | 0 | 0 | 0 | 0 | 0 |
| Article | Q1 | Q2 | Q3 | Q4 | Q5 | Q6 | Q7 |
| Enguix (2005a) | -2 | -2 | -2 | -2 | -2 | -2 | -2 |
| Enguix (2005b) | -2 | -2 | -2 | -2 | -2 | -2 | -2 |
| Dervan et al. (2006) | -2 | -2 | -2 | -2 | -2 | -2 | -1 |
| Hall et al. (2007) | -2 | -2 | -2 | -2 | -2 | -2 | -1 |
| Dervan and McDaniel (2007) | -2 | -2 | -2 | -2 | -2 | -2 | -1 |
| Duval et al. (2007) | -2 | -2 | -2 | -2 | -2 | -2 | -1 |
| Dobrzanski (2007) | -2 | -2 | -2 | -2 | -2 | -2 | -2 |
| Nagle and Golden (2006) | -2 | -2 | -2 | -2 | -2 | -2 | -2 |
| Eysenck and Keane (2005) | -2 | -2 | -2 | -2 | 1 | -2 | -2 |
| Kruk et al. (2007) | -2 | -2 | -2 | -2 | -2 | -2 | -2 |
| Westerski et al. (2006) | -2 | -2 | -2 | -2 | -2 | -2 | -2 |
| Jankowski (2007) | -2 | -2 | -2 | -2 | -2 | -2 | -2 |