Technical Report and Update
Interoperation of COSE with e-Resources (ICE):
Technical Report and Update
Edward Clarke (SURF X4L)
04/10/04
12:28 AM26/07/2016
1 of 56
Technical Report and Update
.
Summary
ICE describes both an on-going project within the University’s Department of
Information Services and the study funded through JISC 05/03 funding for Metadata and
Interoperability Projects. In respect of the latter, this was meant to be a short project of
four months duration, but for various reasons, including the many issues it
highlighted, production of the full report was considerably delayed. It can be
downloaded from http://www.staffs.ac.uk/COSE/cosenew/StaffordshireICEFull.pdf
and is referenced as ‘05/03 ICE’ in what follows.
The SURF (Staffordshire University Regional Federation) X4L project is engaged in
related work in content exchange and re-use, funded under the JISC Exchange for
Learning programme. The overlap between the ICE and SURF X4L is best
encapsulated in the use made of UK LOM metadata and the integration within COSE
of the RELOAD metadata editor. It made sense that SURF X4L would input to the
ICE project, so that it could build on the outputs of the ICE study in at least three
ways. Firstly in making COSE metadata system conformant, COSE content would be
more widely searchable, and so re-usable. Secondly, metadata conformance would
facilitate another SURF X4L objective in importing third party packages: these would
be of more limited value were the host system not metadata conformant. Thirdly,
leveraging our research and experience in working with e-publishers and eaggregators would enable access to other e-resources, particularly those accessible via
the University’s On-line Library (Horizon), but also to a variety of other OPAC
repositories. As the COSE system is free to download and will be made open source
in due course, configurable software used therein would enable institutions using
COSE to link to their own on-line e-resources (z39.50 targets), based on JAFER /
ELF d+ outputs.
This report serves to describe SURF X4L input to 05/03 ICE and to review and
expand on previous observations. This is appropriate in describing in more detail
some of the technical issues and in updating on the further progress made through
SURF X4L, but particularly in considering how to continue technical development.
Introduction
The aim of the project was to integrate the facility to search for e-books and other eresources with existing search capacity in COSE. Particular e-resources or generic
search results returned could be saved as reference objects within the VLE which
would be labelled - tagged with meaningful metadata - to facilitate reuse within the
system. These reference objects would be created as COSE objects drawing
seamlessly on the referenced resources, and could be integrated, packaged and
exported with other content. By using standard metadata these reference objects
would be reusable in other standards conformant systems and tools. Extending the
metadata labelling to other COSE objects was a SURF X4L objective that would
enhance standards conformance of the VLE (metadata system conformance).
12:28 AM26/07/2016
2 of 56
Technical Report and Update
About RROs
The tagged reference objects are discussed in 05/03 ICE as RROs, reusable reference
objects, on which some explanation would be helpful. Essentially, these are simply
web references, and it is important bear this in mind, not to be confused by other
associations relating to them. In the context of the 05/03 project, they might be links
to particular research articles or other e-documents held in some collection; an RRO
might be a web page returning a list of links to such, as search results, or a component
of that page where the html has been parsed and individual links rendered to appear as
separate objects. These links might require authenticated access, but in any case, an
RRO describes a web link. The idea that they are tagged i.e. associated with metadata
descriptors in some way, is meant to indicate they are reusable, assuming that the
VLE, tool or application wherein they reside understands how the web reference is
associated with its metadata and can search on the metadata to present the link to the
user. The idea of being an object relates both the general sense of ‘a thing’, and to the
object-orientated software by which the reference is presented: web references already
exist as objects in COSE but require modifications to render them re-usable, and to
upgrade them as generic COSE components. There is also a clear association with the
concept of a learning object, even if there may be some disagreement about exactly
what that is.
The rationale for introducing RROs both in the context of extant ‘external resources’
(web references) in COSE and in respect of their educational value is discussed in
05/03 ICE. Also relevant here is the concept that all content created in COSE is
structured in accord with COSE pedagogy and is generally capable of being
disaggregated to components so that they can be re-used via COSE Search Tools and
the Basket. While that discussion requires some familiarity with COSE, the important
points are that extant COSE web references aren’t capable of being disaggregated in
the same way as other COSE components and that, currently, COSE Search Tools use
only basic search criteria which could be enhanced in using standard metadata,
especially where this indicates educational relevance.
The focus of 05/03 ICE was in seamless linking to the e-resources of aggregators and
publishers, these links constituting a special case of RRO, which we called Strand B.
We are not especially concerned here with that aspect of the project because that work
was undertaken as ‘contributed effort’ from the COSE development team and is not
directly relevant to SURF X4L. We would say though that the challenges and issues
raised in working with partners ebrary and Emerald were considerable, the most
significant relating to different communications technologies and working with
proprietary formats in mapping metadata as search terms, formulating queries and
interpreting the results returned. This was anticipated in the COSE team developing
the hub and plug-in approach, which we will return to briefly in the context of eresource discovery via JAFER / d+. Strand B work was to build on core Strand A
work in COSE dealing more generally with the introduction of RROs.
Different challenges of 05/03 ICE
In retrospect, it was too ambitious in the time available to expect to be able to address
the multiple challenges which presented in 05/03 ICE. These can be summarised as
follows, some of which are discussed in more detail later:
12:28 AM26/07/2016
3 of 56
Technical Report and Update
(a) Background Research and Context
The initial analysis phase of the project included looking into related background
literature, associated projects and technologies. We had been introduced to the work
of some related projects in attending a JISC cross-programme meeting at Warwick,
July 2003 (OLIVE, X-grain, Balsa, JAFER) so were aware of brokered approaches to
resource discovery, and of OpenURL, which we learned neither of our e-publisher
partners supported. While we weren’t at the time able to explore these technologies
more fully, this was a useful exercise and proved particularly so in respect of JAFER
later.
In respect of different approaches to the problem at hand we initially tried to conduct
searches re-using the e-publishers’ search interface (for more on searching Emerald
and Ebrary see Appendix 1) which would have saved a deal of time mapping search
parameters. Using this ‘quick win’ approach we discovered would require saving
returned results by means of an html editor kit, and so proved not so quick. Such a kit
was used later in saving results returned from Emerald, but raised a number of issues,
discussed in Appendix A of 05/03 ICE.
(b) Extending COSE web references as RROs
We mentioned previously that COSE web references ‘require modifications to render
them re-usable, and to upgrade them as generic COSE components’. For them to be
re-usable, metadata had to be associated with them ‘in some way’, and this is
achieved through introducing a new file format for the system to access web
references, denoted by the .ref extension. Metadata is associated with the reference by
having the same unique name as the reference but with the .xml extension.
The more difficult task was to upgrade these new references as full-blown COSE
components. This was summarised in ‘COSE technical modifications’ (Appendix E of
05/03 ICE, also appended here), an outline identifying key sub-tasks, not an
exhaustive list, and which itself needs updating. There was also the issue of backward
compatibility to deal with i.e. how extant web references in a system be upgraded.
A third matter, which also applies to c) and not considered in much detail previously
lies the distinction to be made between published and unpublished components. While
there is no difficulty in tagging either unpublished or published content, there are
issues associated with publication and export which have yet to be fully explored.
[05/03 ICE refers to published and unpublished components in the idea of educational
object lifecycle, but without the particular comment they merit relating to their role in
any development plan. The points made in respect of metadata are valid but there are
other issues arising so that published and unpublished components would better be
considered as such.]
(c) Extending metadata to other COSE components
12:28 AM26/07/2016
4 of 56
Technical Report and Update
As (b), metadata would be associated with COSE components by having the same
unique name as the component but with the .xml extension. Also, as (b), there are
issues associated with publication and export which have yet to be fully explored.
(for (b) and (c) see ‘COSE technical modifications’, Appendix E of 05/03 ICE, also
appended here)
(d) Metadata implementation and issues
Core to ICE was the adoption of standard metadata schema and integration of the
RELOAD metadata editor. We developed and published an application profile for UK
LOM Core (see Appendix D of 05/03 ICE, also appended here) and the COSE
interface (Basket) was modified to allow launch of the metadata editor. A significant
number of issues were raised in metadata implementation which are discussed below.
(e) Implementing searching
In order to be re-usable, the search facilities in COSE need to be upgraded to search
on full metadata records (components’ .xml files) as well as extant (native) COSE
metadata. Depending on the volume of content in the system there are clear
implications on performance and system load which have yet to be fully explored.
(f) Making packaging modifications
Insufficient consideration was given to making packaging modifications a project
priority in view of the other work that needed to be done. This would allow export of
RROs to standards conformant systems, where the RRO would be viewed as any
other package resource. Different packaging options recently introduced in COSE 2.1
has made the problem more difficult in requiring modifications in scripts associated
with both the packaging routines available.
(g) Implementing Strand B
As mentioned, implementing Strand B required negotiation of a plethora of issues
with e-aggregator partners (see Appendices A – C of 05/03 ICE).
*
The challenges listed above (other than (a)) relate to associating some form of content
with metadata to achieve some level of system metadata conformance. One of the
most significant risks associated with the project and not highlighted as such in ICE
05/03 relates to the unproven benefits versus costs of doing this. It is one thing to try
and be responsive to user feedback to implement desirable features, but may be
another to have to make significant modifications to system architecture and runtime
behaviour which might compromise performance and which is contingent on a level
of user engagement which in this and other areas has proven difficult to attain. This
also applies in other leading edge research in progressing e-learning standards
development. Embedding e-learning to achieve cultural change is not easy. It’s clear
that a certain level of expertise and a good deal of time is involved in generating
content and using metadata to describe it, which we may not in most cases expect of
12:28 AM26/07/2016
5 of 56
Technical Report and Update
academic users, but which falls rather more in the domain of learning technologists
and learning support staff. Even here, it is easy to be confused by a variety of
metadata schema and vocabularies. Simply, most people don’t understand metadata,
else it may be too much trouble to label content accurately, particularly when
considering individual content components. Another significant issue relates to rights
and ownership of metadata especially where the metadata is sourced from different
individuals. It may be for these reasons that a number of VLE vendors, while claiming
conformance do not actually use system metadata for searching: instance
conformance is ‘sold’ as system conformance.
Faced with these issues, it makes sense to reduce the risks by taking a more focussed
and incremental approach (see Priorities below) before attempting further extensions.
We need to educate users in using metadata but also to learn from them, and try and
make using metadata easy for them. Applying metadata to web references, the most
widely used type of resource generally, looks like a good way forward.
Plan and Progress
The items listed in the section above reflect the general plan by which we approached
ICE 05/03. After the initial background research (a), our focus was on the core Strand
A work identified in (b), (d), (e)
(b) Extending COSE web references as RROs involved firstly agreeing a new file
format and system architecture changes for the system to access web references and
their associated metadata across Strand A and Strand B, and secondly, making
modifications to the java code. Upgrading the new references as full-blown COSE
components was made easier in leveraging existing code, considering the objectoriented nature of the programming language, but the complexity of the task was
seriously underestimated. The work remains on-going but at least we were able to
demonstrate critical new features: that external reference objects could be returned as
search results in Search Tools, and that these could be saved to the Basket where
metadata descriptors are attached (see also ‘Listing, Browsing, Selecting and Saving
returned RROs’ of 05/03 ICE).
12:28 AM26/07/2016
6 of 56
Technical Report and Update
Showing the modified search interface and reference objects returned from a
search
Showing reference objects in the Basket modified for metadata editing
12:28 AM26/07/2016
7 of 56
Technical Report and Update
(d) Metadata implementation and issues
‘Metadata implementation’ described in 05/03 ICE relates to integrating the
RELOAD Metadata Editor (see ‘Metadata Editor Development’ of 05/03 ICE).
Launched by clicking on the read / write icons on the Basket, a selected reference
object is tagged by saving the metadata as xml associated with the reference. Figures
illustrate form and tree views of the Editor, and particularly the facility to add
Annotation metadata (with fields for person, date and description) thus rendering
RROs educationally relevant.
Since 05/03 ICE, integration of the RELOAD Metadata Editor has been refined such
that only the internal frame of the parent application is launched, improving
performance, reducing the applet footprint and making for a neater interface. While
we are happy with this aspect of the work, RELOAD is quite a sophisticated tool with
extensions being developed to accommodate other emerging specifications (including
VDEX), so we have yet to explore all of its properties and how much of them we
want to use. For example, where the editor makes it possible to ‘plug in’ schema
alternative to UK LOM CORE, we have still to decide how to handle these options
within COSE.
Addition of ‘annotation’ metadata using the metadata editor: tree view
12:28 AM26/07/2016
8 of 56
Technical Report and Update
Metadata Editor: form view
Issues are considered under separate headings below.
(e) Implementing searching, was given lower priority because this relied on
implementing (b) and (d). Excluding Strand B issues, it was considered quite straight
forward in principle to extend existing search scripts to enhanced metadata (but there
was no focus at this stage in deciding whether this be applied to published or
unpublished content, see below).
As mentioned (f), Making packaging modifications was not considered a priority in
view of the other work that needed to be done first, though ICE 05/03 does suggest
how the work would be progressed (see ‘Modifications required in Packaging RROs’
under ‘Outstanding objectives’). Currently external references are held in index
component and current content packaging makes external references opaque in sense
that they are not exposed either as resource elements nor are they referenced in an
organization element. This is not to say they aren’t ‘accessible’ of course, as they are
rendered as external references in SCOs and in native COSE packages when their
parent index component is interpreted by the host system.
Further work since on our standalone content packages has involved incorporating a
hierarchical organization element whereby reference objects of an index component
are included explicitly as resources to which metadata can be attached These
packaging modifications are key to enabling RROs to be disaggregated and reusable
both within COSE and outside of COSE. The latter case can be easily demonstrated
by manipulating packages containing RROs in RELOAD.
12:28 AM26/07/2016
9 of 56
Technical Report and Update
It should be possible to modify native COSE packaging similarly, and we think there
are ways to address the previously identified issues surrounding the mixed data types
currently allowed in an index component, and granularity (see below)
A substantial amount of development time in ICE 05/03 was devoted to (g)
Implementing Strand B, as described in Stage 2: Design and Development and
Appendices A – C of ICE 05/03. Without in any way meaning to understate these
efforts, we wanted only to describe SURF X4L input to 05/03 ICE, so will not
consider Strand B further here. We also wanted to show how ICE outputs have
benefited SURF X4L and what follows shows how we have started on a parallel
strand of development similar to Strand B but which bypasses a number of issues
associated with e-aggregators and which could also dispense with such radical
adaptation of the search tools interface. Having said that, this work may well be
compatible with the hub and plug-in approach of Strand B (see Appendix C).
Other strands of SURF X4L (e.g. ADL’s SCORM 1.2 runtime environment) and
mainstream COSE development (authentication / single sign-on, (u)portal), other
emerging web service projects) have encouraged us to explore revising COSE
architecture using servlet technologies. The figures below show how we have used the
discovery plus (d+) project toolkit developed under the ELF programme to fire z39.50
queries at our on-line library server (or other targets) to return references which could
potentially be captured as RROs.
Search of various repositories including Staffordshire University’s own on-line
resources (Horizon) using d+ toolkit (based on JAFER)
12:28 AM26/07/2016
10 of 56
Technical Report and Update
Results returned from simple search of Staffordshire University’s on-line
resources (Horizon)
Though we have to fully explore the potential or limitations of this technology, we
find this to be an interesting development in a number of ways. Firstly, it was so easy
to deploy and configure the toolkit, we feel it must be of benefit to a large
constituency. The fact that the project is open source is interesting in terms of its
further development and its longevity / sustainability. Finally it provides a route to
learn new technologies associated with web services (SOAP) and metadata (zING)
and so how exploit these further.
The simple search illustrated allow a single search term without specifying whether
this be a keyword, author’s name or other specific criterion. Clearly the query
interface would be further developed to allow more complex (boolean) and specific
searches. The results page is rendered using a stylesheet and this could be adapted to
allow saving of search results or individual references. We are talking with library
staff and suppliers of the library server to determine exactly what collections and
other resources can be interrogated in this way and what further useful information
might be returned, location of the resource being an obvious example.
12:28 AM26/07/2016
11 of 56
Technical Report and Update
Priorities
Before launching on a lengthy discussion of issues, there is one which we would raise
in helping to determine the direction of further work. This relates to the important
distinction to be made between published and unpublished content in COSE. We can
then consider reference objects before other COSE components.
ICE 05/03 referred to this distinction more implicitly than explicitly in discussing
object lifecycles. Rather too much emphasis was given to the idea of lifecycles,
perhaps, considering metadata input and rights. If we consider unpublished content,
not only are the risks of implementing metadata system conformance greater (in terms
of load, there will always be much more unpublished than published content in a
given system) but substantial modifications would be required to the publication
procedure to associate newly published components with their metadata files.
Considering published content, with particular regard to reference objects and the use
of annotations to render them educationally relevant, these annotations are more
relevant after publication anyway, in so far as they are made by actual users of
approved / quality assured content (cf. reviews). The content authors could easily be
accommodated by being prompted to add metadata during the publication process,
after publication or on export.
In light of this review, our future plan would reflect the tasks listed in ‘COSE
technical modifications’, Appendix E of 05/03 ICE, but we would apply the following
priorities in achieving initial objectives. First, in view of risks associated with
metadata system conformance (excessive system load and reduced performance, and
that costs might outweigh benefits), we would trial a COSE release with tagging of
published content only in the first instance. In respect of packaging, we would explore
the value of packaging tagged reference objects before extending the incorporation of
metadata to other packaged components.
Breaking this down further
1. Prioritise tagging of published reference objects before 4.
2. Implicit in 1., ensure that reference objects are constituted as full blown COSE
components.
3. Search using free text search before attempting to searching on specific metadata
elements / criteria.
4. Extend tagging to more, eventually all, published COSE components.
with regard to packaging
5. Use the new organization element in standalone content to associate enhanced
metadata with reference objects before 6.
6. Associate enhanced metadata with other resources in standalone content.
7. Extend enhanced metadata to native COSE packages.
12:28 AM26/07/2016
12 of 56
Technical Report and Update
also
8. Apply tagging and searching to unpublished components.
9. Investigate associations with emerging specifications (RLI, extensions to
RELOAD, including, for example, VDEX).
10. Address copyright and licensing issues, possibly introducing some licensing
framework within COSE to address some of the issues (cf. use of model licences and
how intralibrary deals with annotations to repository resources)
11. Further explore use of the discovery plus / JAFER toolkit.
We can see that 1-3 and 5 are the core objectives according to ICE 03/05, but that
much more work is implied, even than can be achieved under SURF X4L. Assuming
successful integration of tagged reference objects within COSE, other work would
progress under the wider remit of ICE and mainstream COSE development.
More on Technical Issues
This section expands on various issues raised in 05/03 ICE, some already discussed,
and largely repeats those previously identified
Granularity
a. (may be relevant to d+ / JAFER strand) Results returned from a search of eresources might be (would likely be, before selection of any individual resource) in
the form of a list. While that is not necessarily an issue, the attention is drawn to the
fact because there is no facility at present to further disaggregate such an RRO. This is
one aspect of the wider issue relating to selection and saving of RROs from
returned results, resolved at least in part under Strand B.
b. In respect of ‘convergence’, the relation between highly granular RROs and
reading lists, a collection of RROs (which in the current version of COSE would be
constituents of an index component) could be viewed as a reading list. From a
technical viewpoint, the distinction between RROs and informational objects and their
associated metadata may not be significant. If reading lists can be disaggregated,
convergence will probably be resolved in RLI. This would likely require some
transformation in file formats between COSE and whatever is recommended by RLI.
c. ‘Modifications required in Packaging RROs’ describes how that metadata
associated with RROs would be packaged, and similar considerations would apply in
packaging metadata associated with any COSE component where enhanced metadata
was implemented.. Adding resource level metadata would substantially increase the
size of the package, and the questions of whether this were desirable, whether it
could be included as an option, and on how COSE or other systems use this metadata
remain open.issues at this time.
12:28 AM26/07/2016
13 of 56
Technical Report and Update
d. Another aspect of granularity relates to system load. If RROs are to be searched for
using enhanced metadata, this would substantially increase the load on the system and
some means of optimizing this process would have to be implemented. The problem
would be multiplied if all COSE components use enhanced metadata. In respect of
searching enhanced metadata, the impact of using enhanced metadata needs to be
properly assessed. One way of doing this would be to include an option on the search
tools for searching on enhanced metadata.
Metadata issues
The most significant of these have already been mentioned, but we expand on various
points here aiming to explain more of the detail and in some cases to propose
solutions. Most were discussed in 05/03 ICE under ‘Metadata Development’
a. Reference objects are perceived as having an ‘extended’ lifecycle reflecting how
metadata is input at various stages and an application profile was developed to
record our particular implementation of the UK LOM CORE schema (See Appendix
D). Such profiles should be published by implementers for transparency to allow
proper assessment of the level of conformance.
b. According to our interpretation of primary v secondary metadata, primary
metadata returned with reference objects could be accommodated by the UK LOM
CORE schema. One of the top level elements in the scheme <relation> allows for
data describing the relation of one learning object to another. The sub-elements
include <kind> and <description>. The <kind> element is the kind of relationship and
it is clear that an RRO references some other resource, typically an external URL
(maybe as a selected search result). References is one of the values of the vocabulary
used in the schema, so that is the one used in our application profile. The
<description> element has no structure but allows a free form text description of the
nature of the relation. In our application profile we propose that the first string in this
field is the reference that the RRO relates to followed by metadata relating to this
reference from the e-aggregator. The metadata returned would be different from
different e-aggregators, so a composite XML format would have to be determined.
c. With regard to metadata from the system / COSE itself, In the same way that
system metadata (including a user’s profile information, for example) is used in
providing metadata in content packaging, it can be used in populating the metadata /
xml file associated with an RRO when that is instantiated in COSE. In respect of an
item selected following the return of search results, the RRO is instantiated when
saved in the Basket. Otherwise reference objects are instantiated when saved in the
COSE Component Editor.
d. Important in respect of metadata ownership and rights, it is important to consider
the different contributors. Pro tem, metadata can be added to unpublished RROs by a
user (the author), or by users sharing that RRO with the author, and to published
RROs by anybody accessing the system. This is the whole point of RROs, that
metadata can be added to contextualize the RRO, but it may be that some refinement
of such privileges be revised to discourage abuse or to protect ownership rights.
Metadata can be added under the <annotation> element of the schema according to
our application profile. Sub-elements under <annotation> allow input of
12:28 AM26/07/2016
14 of 56
Technical Report and Update
<description> as free form text, <date> and personal profile details under <person>. A
previous figure shows the input of this data in the RELOAD Editor. This annotation
element would be a key target in enhanced search routines.
e. We have considered publication as an important juncture in dividing technical tasks
associated with future project development but it is firstly an important stage in the
production of content, and it might be advisable to allow a final check on metadata
prior to publication. Similar considerations apply on Export. Certain metadata input
would be required but could be provided by default (e.g. date of publication, status
under <lifecycle>). There are issues on how this would be managed however, as
published content can have a multiplicity of components, and checking metadata for
all of these would likely be too onerous for most users.
f. Considering the COSE export routine, metadata is currently applied to the content
as a whole. It would be possible to include RRO metadata (or that for other COSE
components where enhanced metadata labelling extended to these) transparently, and
this would likely be the best solution (regarding caveats). If included, such metadata
would likely include annotations; if it were considered appropriate in protecting
rights, it would be possible to have these stripped out on export, meaning they would
only be available in the originating system, but that rather undermines the case for
allowing them in the first place. The Import routine would require modification to
associate the imported metadata with the related components
g. ICE 05/03 discusses the difference between educational objects and informational
objects (and ‘convergence’, under ‘RROs and Reading Lists’) but the matter at least
partly reflects the debate around the meaning of learning objects – and that it may be a
matter of opinion what that is. Notwithstanding how such an object be rendered or
interpreted in a given environment, might not a metadata record referencing a
particular web site and containing educationally relevant information be considered
both (or all three) kinds of object? At least one interpretation should be supported on
closer inspection of the RLI specification. Also, while the focus of ICE 05/03 is on
annotation metadata, UK LOM CORE, which is itself subject to further revision,
allows a set of elements under the top level <educational> tag, which have been
criticised as having little value.
h. An RRO or other metadata enhanced COSE component should be re-usable as
other components. If already published and a user wanted to edit it, a new copy would
have to be created. The difference is that an enhanced components exists in
conjunction with its metadata, so a new metadata record would have to be created (i.e.
an editable copy created with a different filename). This re-use of is an example of
one of the issues we have yet to address under ‘Technical Modifications’
i. There are issues surrounding metadata maintenance and with regard to the
Metadata Editor and UK LOM CORE. While it was noted that we wanted to make our
implementation as flexibility as possible, and to balance this with ease of use, there
would inevitably have to be some constraints. For example, rules enforcing element
multiplicity would be required, as there seems no limit to the length of the metadata
record in the specification. Mapping between different schema and versions,
managing emerging specifications and extensions (RLI / VDEX) are clearly other
12:28 AM26/07/2016
15 of 56
Technical Report and Update
concerns, though the fact that the editor code is open sourced and has a community
base in maintaining such offers encouragement that the problem can be contained.
COSE issues
Again, a number the COSE issues listed have already been mentioned, but others have
not and it is useful to have a section to focus on these, and where further detail may be
considered.
a. There are issues surrounding appropriate metadata interfaces. While our work
has taken us to proof of concept, it is likely other revisions would be made in
interfaces to view and edit metadata (partly reflecting rights issues). It is anticipated
that the capacity to search using enhanced metadata would be transparent to most
users i.e. the default search would present an easy-to-use interface, not much more
complicated than the current search tools are to use. The casual user might be
satisfied to view the resource directly in the browser, but the associated metadata
should be more readily viewable than having to save items in the user’s Basket.
Metadata buttons might be required in e.g. the COSE Browser / Editor
b. Users need explicit instructions on how to use the new metadata editor and other
metadata features to be introduced, so new guide would have to be written. The
COSE manual would need updating to describe RROs.
c. Various aspects of importing and exporting have been raised with respect to
metadata: size of packages, input and inspection of metadata, quality of metadata,
cascading metadata between components, option dialogues to facilitate these
processes.
d. In a new round of development, our technical modifications plan would need
revising, not least to include tasks not previously considered, through omission or
otherwise
e. In respect of integration of the Metadata Editor, this was originally developed
through RELOAD as an application and depends on access to files on hard drive. In
being repurposed, the signed COSE applet could access such files specified as
preferences, but to integrate RELOAD functionality such as content packaging and
repurposing is more complicated. Assuming IPR issues are addressed, it may be that
packages are manipulated on the local drive and uploaded to the COSE server.
f. More work is needed on exploring the JAFER / d+ development strand and this
needs to be reconciled with the 05/03 ICE Strand B hub and plug-in approach, else a
decision made that they should not be.
g. With regard to f. and other COSE revisions to use web services and servlets, the
servlet container (Tomcat) needs to be integrated with the web server (Apache)
through connectors and there may be issues considering different web servers and
servlet containers e. g. platforms for these.
h. Even relatively modest modifications of COSE e.g. introducing SCO packaging
option have proven quite burdensome in terms of testing and there is much more of
12:28 AM26/07/2016
16 of 56
Technical Report and Update
this to do under ICE. Consider a brief list of the following to be tested: RROs as
COSE object; search scripts under load; various issues associated with import, export
and publication; revision of search interface; mixed data types currently allowed in an
index component;
Other issues
We have mentioned several times the issues relating to IPR and metadata. While the
problem was most obvious in using primary metadata of the e-publishers, it clearly
applies more widely. As far as COSE is concerned, authors (along with supertutors
and administrators) ultimately have control of what content is published or exported,
but they need to be supported by some copyright framework in relation to metadata,
if metadata is to be used effectively. We will continue to monitor best practice in this
area, especially through the creative commons approach. As noted in ICE 05/03
‘current approaches are led by past practice relating to non-digital information and ..
are inadequate’; instead they ‘need to address the management of the capture, reading
and editing of expressions of rights in a way that takes account of new possibilities for
sharing resources, and that treats both digital content as dynamic and shared, and the
rights themselves as dynamic and shared’, but we don’t expect a consensus on such
frameworks or their practice to emerge in the near term.
In respect of the e-publishers, ICE 05/03 identified risks posed by the technologies
needed to communicate with e-aggregators, including our experience in maintenance
issues relating to changes in proprietary formats. Wider adoption of standards based
technologies (openURL, new generation z39.50) will help in this area, as
demonstrated by JAFER/d+. Similarly, while access and authentication have no
universal solution at present, we are encouraged by initiatives like OPAC.
Lessons learned
ICE 05/03 makes it clear that it was too ambitious to expect to be able to properly
investigate background literature and associated technologies, assimilate external
references as new COSE objects, address metadata issues, develop an application
profile, integrate the RELOAD metadata editor, implement enhanced searching, make
packaging modifications, negotiate a plethora of issues with e-aggregator partners and
further extend metadata system conformance in the time available. Having said that it
was always our plan to continue the work through SURF X4L and the wider
(University) ICE project. The point has been made that projects of this nature are
inevitably progressed iteratively. It seems not possible to anticipate the problems
which present themselves until each layer of complexity is revealed in different cycles
of development. Even in this review, issues are mainly highlighted as such rather than
being addressed in detail.
The work continues to progress and doubtless RROs and RELOAD will feature in a
proximate COSE release. The point has been made in respect of the costs and benefits
of metadata conformance. In retrospect, it would have been better to focus on a basic
implementation and done more evaluation work than try to address packaging and
export of RROs or other objectives. Besides the real enhancements achieved through
the project, ICE 05/03 has proven valuable as a scoping exercise, and reviewing the
project has enabled us to plan the development ahead
12:28 AM26/07/2016
17 of 56
Technical Report and Update
Appendix 1
Project Partners
Ebrary is funded by Random House Ventures LLC, Pearson plc and The McGrawHill Companies. It provides access to 15000+ e-books in PDF format from 175+
publishers.
The subscription allows multi user simultaneous access via the web and allows print
and copy and paste reproduction. Staffordshire University were the first UK
subscribers to the product in 2002 and have subsequently been quoted as best practice
providers of e-books in HE in a recent report to JISC. Ebrary is used widely for all
courses and awards, both on and off campus.
http://www.ebrary.com/company/
Emerald is the trading name of Emerald Group Publishing Limited and provides
access to a wide range of journals and journal articles. The University has subscribed
to this aggregated service for a number of years and the titles are well embedded in
the course learning resource delivery of the institution.
http://www.emeraldinsight.com/
Interfaces: Ebrary
Ebrary advanced search
12:28 AM26/07/2016
18 of 56
Technical Report and Update
Search results returned in Ebrary: such items as would be captured as
RROs
On selecting item, pdf document shows cover page and contents list
12:28 AM26/07/2016
19 of 56
Technical Report and Update
Selecting the contents page
Interfaces: Emerald
Emerald advanced search
12:28 AM26/07/2016
20 of 56
Technical Report and Update
Search results returned with minimal data
Selecting item returns publisher data and options for viewing document
12:28 AM26/07/2016
21 of 56
Technical Report and Update
Viewing the document : more primary metadata returned here
12:28 AM26/07/2016
22 of 56
Technical Report and Update
12:28 AM26/07/2016
23 of 56
Technical Report and Update
Appendix D: ICE Application Profile
COSE UK LOM CORE Application Profile Version 1.0
This document is intended to describe the application profile for Reusable Reference
Objects in COSE, based on UK LOM CORE. The profile is meant to be as flexible as
possible, so as few elements as possible (where their meaning is clear) are ‘not
recommended’ for use. Those that are ‘recommended’ would be important target
fields for searching (pro tem by modifications to existing script). Implementation notes
apply as they relate to the profile known as UKCMF v. 1.0 in RELOAD. Of particular
relevance are the relation and annotation elements.
This is a draft profile subject to further revision, particularly in view of (VDEX and) the
emerging RLI specification: profiles are produced partly to enable interoperability,
and as it is beyond the remit of this project to test interoperability in respect of RROs
(and resource lists). COSE Notes should be read in conjunction with Explanation /
UK LOM Core Notes. Further notes will be added later to deal explicitly with
multiplicity of elements.
COSE ‘level’ key is meant to indicate at what point various metadata is input (see
sections Educational Object Lifecycles and Metadata development.)
1.
2.
3.
4.
5.
incoming metadata
COSE system added metadata
user added metadata
at publication / post publication
at export
Eleme Element
nt
Name
Numb
er
General
identifier
1.1.1
Catalog
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
This category groups
M
the general information
that describes this
learning object as a
whole.
A globally unique label Use
a
formal M
that identifies this
identification
system
learning object.
where possible. E.g.
DOI, ISBN. Refer to
the IMS "Persistent,
Location-Independent,
Resource
Identifier
Implementation
Handbook"
http://www.imsglobal.or
g/implementationhandbo
ok/imsrid_handv1p0.htm
l for further guidance.
The name or
If
the
originating M
designator of the
organisation has a
identification or
cataloguing system in
cataloguing scheme fir place then it should be
this entry. A
used, otherwise use
12:28 AM26/07/2016
24 of 56
COSE
level*
COSE Implementation
Notes
2
not intending to use,
at least not until it is
known to be required
in export of RRO
Technical Report and Update
Eleme Element
nt
Name
Numb
er
1.1.2
1.2
1.3
1.4
Explanation
UK LOM Core
Implementation
Guidelines
namespace scheme.
the notation of the
repository the learning
object
resides
in.
Publishers are advised
to register with DOI.
If
the
originating
organisation has a
unique
identification
system in place then it
should
be
used,
otherwise use a GUID
following
IMS
guidelines.
http://www.imsglobal.or
g/implementationhandbo
ok/imsrid_handv1p0.htm
l
Name given to this
Transcribe the title
title
learning object
preserving the original
wording, order and
spelling.
Only
capitalize
proper
nouns.
Punctuation
need not reflect the
usage of the original.
Subtitles should be
separated from the title
using a colon (':'). This
element may not be
repeated, so only one
title may be encoded.
The
primary
human
This
element
is
language
language or languages mandatory as the UK
used within this
is multi-lingual (ethnic,
learning object to
Welsh, Gaelic, etc.)
communicate to the
and as we are part of
intended user.
European Union. The
appropriate
two
character ISO 3639-1
country code should
also be used.
The
default entry for this
element is 'en-GB'.
description A textual description of The description should
the content of this
be a concise, keywordlearning object.
intensive description of
the object. If the
learning object has an
abstract or table of
contents,
that
information can be
included here. The
general
description
should
not
be
entry
The value of the
identifier within the
identification or
cataloguing scheme
that designates or
identifies this learning
object. A namespace
specific string.
12:28 AM26/07/2016
25 of 56
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
metadata: this could
be revised under RLI
spec.
could be system
generated
M
2
not intending to use,
at least not until it is
known to be required
in export of RRO
metadata: this could
be revised under RLI
spec.
could be system
generated
M
2
recommended.
RELOAD allows
multiple values: would
not recommend such
until this is known to
be the strong
preference of user
community
M
3+
recommended.
could be system
generated
(as ‘en’ and see below**)
M
3+
recommended.
Technical Report and Update
Eleme Element
nt
Name
Numb
er
1.5
keyword
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
confused
with
the
educational description
of the object.
Keywords or phrases These keywords
O
describing this learning should ideally be
object.
created by the author
This data element
of the resource and
should not be used for not through a
characteristics that can classification process.
be described by other In general, choose the
data elements.
most significant and
unique words for
keywords, avoiding
those too general to
describe a particular
object. If the subject of
the learning object is a
person, enter their
name using the
'familyname,
forename' format. For
example:
COSE
level*
COSE Implementation
Notes
3+
recommended.
Shakespeare, William
If the subject of the
learning object is an
organisation, enter its
name. If the name is
hierarchical, list the
parts of the hierarchy
from largest to
smallest, separated by
full stops. For
example:
Bank of England
1.6
coverage
For multiple free-text
keywords repeat the
element for each term.
Refer to Dublin Core
The time, culture,
O
geography or region to Coverage element:
which this learning
Typically, Coverage
object applies.
will include spatial
location (a place name
or geographic
coordinates), temporal
period (a period label,
date, or date range) or
jurisdiction (such as a
named administrative
entity). Recommended
best practice is to
select a value from a
controlled vocabulary
12:28 AM26/07/2016
26 of 56
optional
Technical Report and Update
Eleme Element
nt
Name
Numb
er
1.7
structure
Explanation
Underlying
organizational
structure of this
learning object.
12:28 AM26/07/2016
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
(for example, the
Thesaurus of
Geographic Names
[TGN]) and to use,
where appropriate,
named places or time
periods in preference
to numeric identifiers
such as sets of
coordinates or date
ranges.
http://www.dublincore.or
g/documents/dces/
Refer to CanCore:
O
CanCore does not
recommend the use of
this element.
Structure refers to the
way in which individual
objects are logically
related to form
aggregate or
composite objects.
(By contrast,
1.8:Aggregation Level
refers to the number of
times an object can be
decomposed into still
smaller component
parts, independent of
the kind of
relationships between
them.)
Objects incorporating
multiple levels of
aggregation will likely
include more than one
kind of structure. The
expressive power of
this element is
consequently limited in
that it does not
accommodate more
than one value, and
does not recommend a
value that indicates
that a multiplicity of
structures are
incorporated into a
single aggregate
object. It is also not
clear how the
underlying structure of
a resource might relate
to learning styles or
user preferences. The
27 of 56
COSE
level*
COSE Implementation
Notes
optional
from vocab list supplied,
could take value ‘atomic’
seems little value in
using this element
Technical Report and Update
Eleme Element
nt
Name
Numb
er
1.8
aggregatio The functional
granularity of this
n level
learning object.
lifecycle
2.1
2.2
Explanation
version
status
This category
describes the history
and current state of
this learning object
and those who have
affected this learning
object during its
evolution.
The edition of this
learning object.
The completion status
if condition of this
learning object
12:28 AM26/07/2016
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
fact that this element
recommends the use
of non-numeric
vocabulary values also
presents difficulties for
implementation in
multilingual contexts.
http://www.cancore.ca/d
ocuments.html
Use as is, if at all, until O
such time as there is
generally
agreed
consensus as to how
this element can be
used appropriately. It
is not recommended
that that this element
is used as part of the
basic UK LOM Core
element set. Other
application profiles of
the LOM may wish to
make this element
mandatory to support
ongoing work (from UfI
and
others)
on
categorising levels of
learning objects.
M
As
many
learning O
object developers may
not use formal version
control
methods,
appropriate use of this
element can not be
gauranteed
and
consequently it is not
mandatory. However
developers of learning
objects are strongly
encouraged
to
systematically control
versions
of
their
resources.
As
many
learning O
object developers may
not use formal version
control
methods,
28 of 56
COSE
level*
COSE Implementation
Notes
not recommended
optional
could be used
in tracking updates
to the metadata
recommended
source / value pair
vocab. includes
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
COSE
level*
‘draft’,‘final’
appropriate use of this
element can not be
guaranteed
and
consequently it is not
mandatory.
This
element may prove
useful for resources
held in repositories
that are not
yet
publicly available, or
resoruces that have
previously
been
available but have
subsequently
been
withdrawn.
2.3
contribute
2.3.1
role
2.3.2
entity
Those entities (i.e.,
M
people, organizations)
that have contributed
to the state of this
learning object during
its life cycle (e.g.,
creation, edits,
publication).
Kind of contribution.
For
commercially M
sourced
learning
objects
or
those
created by institutions
or
projects
the
minimum mandatory
requirement
is
'publisher'. For objects
created by teachers or
lecturers 'author' sould
be used to denote the
person who created
the
object
and/or
'publisher' for their
institution/employer.
Multiple authors may
be recorded.
The identification of
The
mandatory M
and information about minimum set of vCard
people or
elements is "name"
organizations
and
"organisation
contributing to this
name".
Use this
learning object, most
element to provide
relevant first.
information about the
author
and/or
publisher
of
the
learning object by
setting '2.3.1 role' to
'author' or 'publisher'
as
appropriate.
Structure the value
according to vCard.
12:28 AM26/07/2016
29 of 56
COSE Implementation
Notes
2
Recommended
source / value pair
vocab. includes
‘author’
could be system
generated
2
Recommended
could be system
generated using COSE
profile metadata
use vCard as described
in COSE manual
Technical Report and Update
Eleme Element
nt
Name
Numb
er
2.3.3
date
metametadata
3.1
identifier
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
Use the 'FN' and
'ORG' vCard elements
for
"name"
and
"organisation name",
enclosed
between
'BEGIN:VCARD' and
'END:VCARD'.
Additional
vCard
elements may be used
but it is recommended
that the total number
of
elements
used
should be kept to a
minimum for the sake
of simplicity. Separate
vCard
components
with '\n' and escape ';'
and ',' using '\;' and '\,'
where
these
characters appear in a
component
value.
Multiple authors may
be recorded.
The date of the
Typically this will be O
contribution.
the date of creation or
publication for the
learning object. The
preferred method for
recording a date is the
YYYY-MM-DD format.
In most instances it is
sufficient to record
year and month, in
which case use the
first day of the month.
This element could be
used to identify a
specific version of a
resource
in
the
absence of a formal
method of version
control. A description
of the date is also
acceptable.
This category
The
meta-metadata M
describes this
elements describe the
metadata record itself creation
of
the
metadata record, not
(rather than the
learning object that
the creation of the
this record describes). learning object itself.
A globally unique label The metadata identifier M
that identifies this
is in the domain of the
metadata record.
system in which the
12:28 AM26/07/2016
30 of 56
COSE
level*
COSE Implementation
Notes
2
Recommended
could be system
generated on
instantiation or
publication of RRO
Our conception of RRO
is that metadata record
approximates to learning
object. This element
duplicates metadata
elsewhere, except in
respect of metadata
scheme and language
not intending to use,
at least not until it is
Technical Report and Update
Eleme Element
nt
Name
Numb
er
3.1.1
3.1.2
catalog
entry
3.2
contribute
3.2.1
role
Explanation
UK LOM Core
Implementation
Guidelines
This is not and shall
not be used, as there
is no specified method
for the creation of a
globally unique
identifier.
metadata record is
created. For example
a digital repository
system
would
be
responsible
for
populating the metametadata values.
known to be required
in export of RRO
metadata: this could
be revised under RLI
spec.
If
the
originating M
organisation has a
cataloguing system in
place then it should be
used, otherwise use
the notation of the
repository
the
metadata
record
resides in. Publishers
are advised to register
with DOI.
not intending to use,
at least not until it is
known to be required
in export of RRO
metadata: this could
be revised under RLI
spec.
If the originating
M
organisation has a
unique identification
system in place then it
should be used,
otherwise use a GUID
following IMS
guidelines.
http://www.imsglobal.or
g/implementationhandbo
ok/imsrid_handv1p0.htm
l
M
not intending to use,
at least not until it is
known to be required
in export of RRO
metadata: this could
be revised under RLI
spec.
The name or
designator of the
identification or
cataloging scheme for
this entry. A
namespace scheme.
The value of the
identifier within the
identification or
cataloging scheme
that designates or
identifies this metadata
record. A namespace
specific string.
UK
LOM
Core
Use
Those entities (i.e.,
people or
organizations) that
have affected the state
of this metadata
instance during its life
cycle (e.g., creation,
validation).
Kind of contribution.
It is important to trust M
Exactly one instance
the
validity
of
of creator should exist. information contained
in a metadata record
therefore the creator of
the
record
is
mandatory.
COSE
level*
COSE Implementation
Notes
could be system
generated
could be system
generated
could be system
generated
recommended
source / value pair
vocab. includes
‘creator’
could be system
generated
3.2.2
entity
The identification of
and information about
the people or
organizations
12:28 AM26/07/2016
The
mandatory M
minimum set of vCard
elements is "name"
and
"organisation
31 of 56
recommended
could be system
generated using COSE
Technical Report and Update
Eleme Element
nt
Name
Numb
er
3.2.3
3.3
date
metadata
scheme
Explanation
UK LOM Core
Implementation
Guidelines
contributing to this
metadata instance,
most relevant first.
name". It would be
preferable
for
this
information
to
be
generated
automatically by the
system from its record
of registered users.
Structure the value
according to vCard.
Use the 'FN' and
'ORG' vCard elements
for
"name"
and
"organisation name",
enclosed
between
'BEGIN:VCARD' and
'END:VCARD'.
Additional
vCard
elements may be used
but it is recommended
that the total number
of
elements
used
should be kept to a
minimum for the sake
of simplicity. Separate
vCard
components
with '\n' and escape ';'
and ',' using '\;' and '\,'
where
these
characters appear in a
component value.
The date should be
M
generated
automatically by the
repository system and
recorded in the YYYYMM-DD format.
The date of the
contribution.
The name and version
of the authoritative
specification used to
create this metadata
instance.
UK
LOM
Core
Use
This element can refer M
either to a formal
standard
metadata
scheme e.g.LOMv1.0,
or
an
application
profile of a scheme
e.g. UK LOM Core.
COSE
level*
COSE Implementation
Notes
profile metadata
use vCard as described
in COSE manual
recommended
could be system
generated on
instantiation or
publication of RRO
2
recommended
could be system
generated on
instantiation or
publication of RRO
value would be ‘LOMv1.0’
consistent with source
given in source/value
pairs in RELOAD
3.4
language
Language of this
metadata instance.
This is the default
language for all
LangString values in
12:28 AM26/07/2016
The default value for M
this element is "en".
This value should be
generated
automatically by the
32 of 56
2
recommended.
could be system
generated
Technical Report and Update
Eleme Element
nt
Name
Numb
er
technical
4.1
4.2
4.3
format
size
location
Explanation
UK LOM Core
Implementation
Guidelines
this metadata
instance. If a value for
this data element is
not present in a
metadata instance,
then there is no default
language for
LangString values.
This category
describes the technical
requirements and
characteristics of this
learning object.
Technical data type(s)
of (all the components
of) this learning object.
system.
If
the
language requires an
additional
country
identifier ISO 31661:1997
should
be
used.
The size of the digital
learning object in bytes
(octets). The size is
represented as a
decimal value (radix
10). Consequently,
only the digits "0"
through "9" should be
used. The unit is
bytes, not Mbytes, GB,
etc. This data element
shall refer to the actual
size of this learning
object. If the learning
object is compressed,
then this data element
shall refer to the
uncompressed size.
A string that is used to
access this learning
object. It may be a
location (e.g.,
Universal Resource
Locator), or a method
that resolves to a
location (e.g.,
Universal Resource
Identifier). The first
element of this list
12:28 AM26/07/2016
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
(as ‘en’)
M
Use MIME types only. M
LOM stipulates that
the technical data
types
of
all
compenents
are
recorded. For example
for a Flash animation
in an HTML Web
page,
repeat
this
element to encode
both 'text/html' and
'application/xshockwave-flash'.
Ideally the size of the O
learning object should
be generated
automatically by the
packing tool or
repository system.
Although LOM
stipulates that the
number is stored in
bytes it should be
displayed to the user
in the most appropriate
format eg Kb, Mb etc.
The size must refer to
the uncompressed
size of the resource.
3+
This refers to the
M
location of the object
rather than the location
of the metadata
record. The value must
resolve to a location
where the learning
object can be found
e.g. a URL. If the
resource is held in a
repository system this
3+
33 of 56
optional
could be system
generated as ‘xml’
seems little value in
using this element
3+
optional
could be system
generated
seems little value in
using this element
Optional
location could be
given but would
require authenticated
access to the particular
COSE installation
(location of the
referenced object is
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
shall be the preferable element would refer to
location.
the location of the
object in the repository
and should be
generated
automatically.
For bibliographic
physical objects
(books and journals),
encode an OpenURL
as follows:
COSE
level*
COSE Implementation
Notes
given under relation)
openurl:?genre=article
&atitle=Information%2
0gateways:%20collabo
ration%20on%20conte
nt&title=Online%20Info
rmation%20Review&is
sn=1468527&volume=24&spag
e=40&epage=45&artn
um=1&aulast=Heery&
aufirst=Rachel
4.4
requireme The technical
capabilities necessary
nt
for using this learning
object. If there are
multiple requirements,
then all are required,
i.e., the logical
connector is AND.
Note that this has
been wrapped for
readability. For nonbibliographic physical
resources (e.g. VHS
videos), provide the
URL of a Web page or
service that describes
how to obtain the
resource.
Refer to CanCore:
O
For the reasons given
below, CanCore does
not recommend the
use of this aggregate
element.
CanCore recommends
that any technical
requirements be
expressed in human
readable form in
4.6:Other Platform
Requirements.
This aggregate
element and its
recommended
vocabularies can
enable precise,
formalized statements
to describe software
12:28 AM26/07/2016
34 of 56
not recommended
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
needed for a learning
object. These
statements can specify
the type, name, and
permissible version
numbers or number
ranges for the required
technology. This
aggregate element
also allows record
creators to indicate
whether all such
requirements need to
be satisfied (using the
Boolean connector
"And", and repeating
element
4.4:Requirement), or
whether only one of a
group of requirements
needs to be met (using
the Boolean connector
"Or", and repeating
element 4.4.1
OrComposite).
The implementation of
this aggregate element
may present
challenges, and can
be avoided by
exploiting other LOM
elements:
It may be difficulty to
establish and maintain
vocabulary values for
4.4.1.2:Name.
Browsers and
operating systems are
developing rapidly and
proliferating as they
move into mobile
devices and
information
appliances. The
suggested value
“netscape
communicator”, for
example, is already
superannuated.
Maintaining a list of
such software is
difficult (and testing
requirements against
such a list, likely
prohibitive).
12:28 AM26/07/2016
35 of 56
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
Requirement
statements will
describe conditions
that cannot be
accommodated in the
formalized elements
and permissible
values. For example,
this aggregate element
lacks a qualifier to
indicate that certain
software is optimal or
preferred.
The recommended
vocabulary for
4.4.1.1:Type
("operating system",
"browser") may be
insufficient for
expressing some
technical requirements
(e.g. those related to
computer hardware,
network capabilities,
etc.)
General software
requirements
information is already
implied in the MIME
type values supplied in
4.1:Format.
As the LOM notes for
element 4.6:Other
Platform
Requirements, "This
element is intended for
descriptions of
requirements that
cannot be expressed
by data element
4.4:Technical.Require
ment." Given the
expressive limitations
that apply to element
4.4, CanCore
recommends the use
of 4.6: Other Platform
Requirements for the
description of all
technical requirements
not already indicated
by 4.1:Format.
12:28 AM26/07/2016
36 of 56
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
Grouping of multiple
or
composite requirements. The
composite requirement
is satisfied when one
of the component
requirements is
satisfied, i.e., the
logical connector is
OR.
The technology
4.4.1.1 type
required to use this
learning object. E.g.
hardware, software,
network, etc
Name of the required
4.4.1.2 name
technology to use this
learning object.
O
Lowest possible
version of the required
technology to use this
learning object.
4.4.1.4 maximum Highest version of the
technology known to
version
support the use of this
learning object.
4.5
installation Description of how to Refer to CanCore:
install this learning
remarks
object.
It is useful only in
exceptional cases,
where an educational
object is stand-alone
software requiring
special installation
procedures.
O
4.4.1
COSE Implementation
Notes
5
not recommended
O
O
4.4.1.3 minimum
version
It is of limited use for
resource discovery
and selection
(installation
instructions are not
likely to form a primary
criterion for the
selection of resources
by students or
educators).
For those objects
requiring it, installation
information is likely to
be provided with the
object itself (e.g. in a
"readme" file), and
would preferably be
presented via a set-up
12:28 AM26/07/2016
COSE
level*
37 of 56
O
O
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
"wizard" or other
mechanism developed
for increased usability.
When an educational
object is a stand-alone
software item requiring
special installation
procedures,
instructions for
installation can be
included using this
element.
4.6
other
platform
requireme
nts
Information about
other software and
hardware
requirements.
4.7
duration
Time a continuous
learning object takes
when played at
intended speed.
This category
describes the key
educational or
pedagogic
characteristics of this
learning object.
This is the pedagogical
information essential
to those involved in
achieving a quality
learning experience.
The audience for this
metadata includes
teachers, managers,
authors and learners.
interactivit Predominant mode of Until the vocabulary for O
learning supported by this element is used
y type
this learning object
more
widely
by
educators it will remain
relatively obscure and
therefore can not be
mandatory.
Further
work is required to
develop
an
understanding of this
education
al
5.1
http://www.cancore.ca/d
ocuments.html
Use as a general O
comment element to
describe any technical
information the user
may require in order to
use the object that has
not
already
been
described
in
4.1
technical format.
Should only be used to O
describe time based
media
files,
e.g.
sound,
video
or
animation.
O
12:28 AM26/07/2016
38 of 56
not recommended
not recommended
3+
not recommended
Technical Report and Update
Eleme Element
nt
Name
Numb
er
5.2
5.3
5.4
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
element
and
its
common usage.
Specific kind of
Work is required to O
learning
learning object. The
develop
an
more
resource
most dominant kind
meaningful
type
shall be first.
vocabulary. In the
meantime use the
LOM vocabulary if it is
appropriate.
Until the vocabulary for O
interactivit The degree of
interactivity
this element is used
y level
characterising this
more
widely
by
learning object.
educators it will remain
Interactivity in this
relatively obscure and
context refers to the
therefore can not be
degree to which the
mandatory.
Further
learner can influence
work is required to
the aspect or
develop
an
behaviour of the
understanding of this
learning object.
element
and
its
common usage.
It is recognised that O
semantic The degree of
conciseness of a
educators
routinely
density
learning object. The
make judgements on
semantic density of a the appropriateness of
learning object may be learning
resources
estimated in terms of
based on a subjective
its size, span or – in
notion of 'semantic
the case of self-timed density', even though
resources such as
the may not use this
audio or video –
term. For example a
duration.
children's book may be
at
an
appropriate
reading
level
but
contains too much
detail on a subject
area to be of use for a
particular pupil, it is too
semantically dense. At
the moment it is
difficult to see how this
element could be used
in the context of
learning
objects
without more objective
methods
of
determining the value.
Until the vocabulary in
this element is used
more
widely
by
educators it will remain
relatively obscure and
therefore can not be
mandatory. Work is
required to develop an
12:28 AM26/07/2016
39 of 56
COSE
level*
COSE Implementation
Notes
3+
not recommended
not recommended
not recommended
Technical Report and Update
Eleme Element
nt
Name
Numb
er
5.5
5.6
5.7
5.8
Explanation
UK LOM Core
Implementation
Guidelines
understanding of this
element
and
its
common usage.
Principal user(s) for
Until the vocabulary for
intended
which this learning
this element is used
end user
object
was
designed,
more
widely
by
role
most dominant first.
educators it will remain
relatively obscure and
therefore can not be
mandatory.
Further
work is required to
develop
an
understanding of this
element
and
its
common usage.
The principal
The
reccomended
context
environment within
vocabulary for this
which the learning and element is now UK
use of this learning
LOM Core v0p1s. This
object is intended to
contains
terms
take place.
relevant to the UK
educational context.
This element should
typical age Age of the typical
intended user.
only refer to the
range
chronological age of a
user and not their
developmental
age.
Therefore the element
is used to indicate the
appropriateness of the
object for a particular
age
group.
Developmental 'age' or
level
should
be
described uding 9.1
Purpose 'Educational
Level'.
This data element
It is recognised that
difficulty
defines how hard it is educators
routinely
to work through this
make judgements on
learning object for the the appropriateness of
typical target
learning
resources
audience.
based on a subjective
notion of 'difficulty',
even though the may
not use this term. At
the moment it is
difficult to see how this
element could be used
in the context of
learning
objects
without more objective
methods
of
determining the value.
Until the vocabulary in
12:28 AM26/07/2016
40 of 56
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
O
3+
not recommended
O
3+
recommended
vocab values include
‘Higher Education’
O
O
3+
Technical Report and Update
Eleme Element
nt
Name
Numb
er
5.9
5.10
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
this element is used
more
widely
by
educators it will remain
relatively obscure and
therefore can not be
mandatory. Work is
required to develop an
understanding of this
element
and
its
common usage.
Approximate or typical As
there
is
no O
typical
time it takes to work
commonly
accepted
learning
with or through this
method of determining
time
learning object for the how long a learner
typical intended target should work with any
audience.
given
object,
this
element should be
used with caution.
description Comments on how this This element
O
learning object is to be describes possible
used.
educational uses for
an object. For example
"use as an introduction
to the topic". This
element should not be
confused with 1.4
general.description.
5.11
language
The human language
used by the typical
intended user of this
learning object.
6
rights
6.1
cost
This category
describes the
intellectual property
rights and conditions
of use for this learning
object.
Whether use of this
If "yes", details of the
learning object
actual cost sould be
requires payment.
included in 6.3
description.
6.2
If "yes", details of the
copyright Whether copyright or
other
restrictions
apply
restrictions sould be
and other
to
the
use
of
this
included in 6.3
restrictions
12:28 AM26/07/2016
This is distinct from 1.3 O
language.
For
example, an object
design to support the
teaching of French for
English
speakers
could have 1.3 = 'fr'
and 5.11 = 'en', that is,
it is a resource in
French designed to be
used by a student
who's first language is
English.
M
41 of 56
COSE
level*
COSE Implementation
Notes
3+
not recommended
3+
3+
O
6
recommended
M
6
recommended
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
learning object.
description.
6.3
description Comments on the
conditions of use of
this learning object.
7
relation
This category defines
the relationship
between this learning
object and other
learning objects, if any.
A description of costs,
copyright restrictions,
conditions of use or
where to find further
information regarding
usage rights.
M
Appropriate use of O
these elements
can be labour
intensive. Refer to
CanCore for
further guideance:
When creating
guidelines for the
use of the
Relation element
group, keep in
mind the
functionality of the
metadata in both a
local and
interoperable
environment. In a
local environment
it may be
desirable and
possible to exert a
tight control over
the relationships
among learning
resources. In an
interoperable
environment,
there may not be
the same controls
in place for
associating one
learning object
with another.
Relational
associations will
likely not be
implemented
comprehensively
or may be
implemented with
12:28 AM26/07/2016
UK
LOM
Core
Use
42 of 56
COSE
level*
COSE Implementation
Notes
recommended
COSE uses this field to
associate the metadata
with the referenced
object, typically a URL.
pro tem, we do not use
the resource element to
identify the referenced
resource. see description
element.
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
3+
recommended
a degree of
redundancy in a
distributed
environment.
Furthermore,
remote resources
that an indexer
may wish to point
at may not be
maintained thus
necessitating
ongoing
maintenance of a
metadata record.
http://www.cancor
e.ca/documents.ht
ml
7.1
kind
Nature of the
relationship between
this learning object
and the target learning
object, identified by
7.2:Relation.Resource.
Refer to CanCore: O
The vocabulary
values for this
element
correspond with
the qualifiers for
DC.Relation. This
element provides
the context for the
relationship
between the
learning resource
described by the
metadata record
and another
learning resource.
CanCore
recommends the
use of the
DC.Relation
Qualifier
vocabulary. Refer
to this vocabulary
and not that of
LOM 1.0 in the
vocabulary data
structure of this
12:28 AM26/07/2016
43 of 56
could be system
generated. typically
would have value
‘references’
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
element.
The LOM
vocabulary and
the Dublin Core
vocabulary on
which it is based
differ in two
respects. The
LOM vocabulary
omits DC's
"Replaces" and
"isreplacedby"
vocabulary pairing
and substitutes it
with an
"isbasedon" and
"isbasisfor"
pairing. LOM does
not provide any
rationale for this
change nor does it
define its
vocabulary terms.
To maximize
interoperability
with Dublin Core,
CanCore
recommends
using the DC
Relation qualifier
vocabulary
(http://www.dublin
core.org/documen
ts/dcmesqualifiers/#relation
).
http://www.cancor
e.ca/guideliens.ht
ml
7.2
resource
The target learning
object that this
relationship
references.
12:28 AM26/07/2016
Refer to CanCore: O
This element
group contains a
44 of 56
recommended use of
description sub-element
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
range of subelements sufficient
for describing the
related resource:
"identifier"
"description" and
"catalogentry" with
its children
"catalog" and
"entry". This
element group
should be used to
refer to the related
resource itself and
not to any
accompanying
metadata record.
If the related
resource exists
only as a
metadata record,
then refer to it in
that context.
http://www.cancor
e.ca/guideliens.ht
ml
7.2.1
identifier
7.2.1.1 catalog
A globally unique label
that identifies the
target learning object.
Use a formal
O
identification
system where
possible. E.g.
DOI, ISBN. Refer
to the IMS
"Persistent,
LocationIndependent,
Resource
Identifier
Implementation
Handbook"
http://www.imsglo
bal.org/implement
ationhandbook/im
srid_handv1p0.ht
ml for further
guidance.
not recommended
The name or
designator of the
identification or
If the originating
O
organisation has a
cataloguing
not recommended
12:28 AM26/07/2016
45 of 56
Technical Report and Update
Eleme Element
nt
Name
Numb
er
7.2.1.2 entry
7.2.2
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
cataloguing scheme
fot his entry. A
namespace scheme
system in place
then it should be
used, otherwise
use the notation of
the repository the
learning object
resides in.
Publishers are
advised to register
with DOI.
The value of the
identification or
cataloguing scheme
that designates or
identifies the target
learning object. A
namespace specific
string.
If the originating
O
organisation has a
unique
identification
system in place
then it should be
used, otherwise
use a GUID
following IMS
guidelines.
http://www.imsglo
bal.org/implement
ationhandbook/im
srid_handv1p0.ht
ml
not recommended
Refer to CanCore: O
The URL is given as the
first string in the free form
description element
followed by an empty line,
followed by metadata
returned by e- aggregator
description Description of the
target learning object.
This element
should contain just
enough
information to
provide the enduser with a
context for what
the related
resource is. A
short title or
simple phrase
description is all
that is necessary.
The character
maximum for this
element is 1000.
CanCore
recommends that
descriptions fall
well within this
12:28 AM26/07/2016
46 of 56
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
prescribed
maximum. Keep in
mind that this
element is
intended only to
identify what the
related resource is
to the enduser. It
is not meant to act
as a surrogate
metadata record
for that resource.
In a multi-lingual
environment, use
a single
description
element with
multiple langstring
sub-elements.
http://www.cancor
e.ca/guideliens.ht
ml
8
annotation This category provides
comments on the
educational use of this
learning object, and
information on when
and by whom the
comments were
created. This category
enables educators to
share their
assessments of
learning objects,
suggestions for use,
etc.
8.1
person
Entity (i.e. people,
organisation) that
created this
annotation.
12:28 AM26/07/2016
Implementors and O
educators should
aspire to using the
annotation
category elements
as they have the
potential to
significantly
enhance the
richness of the
metadata record
by recording
additional
qualitative
information about
the obejct and its
usage.
The
O
recommended
minimum set of
vCard elements is
"name" and
"organisation
name". It would
47 of 56
The key element
recommended in
associating contextual
information with a
reference
3+
recommended.
could be system
generated for author
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
COSE
level*
O
3+
This element can O
be used to enable
educators to
describe the
3+
COSE Implementation
Notes
be preferable for
this information to
be generated
automatically by
the system from
its record of
registered users.
Structure the
value according to
vCard. Use the
'FN' and 'ORG'
vCard elements
for "name" and
"organisation
name", enclosed
between
'BEGIN:VCARD'
and
'END:VCARD'.
Additional vCard
elements may be
used but it is
recommended
that the total
number of
elements used
should be kept to
a minimum for the
sake of simplicity.
Separate vCard
components with
'\n' and escape ';'
and ',' using '\;'
and '\,' where
these characters
appear in a
component value.
Date that this
annotation was
created.
8.2
date
8.3
description The content of this
annotation.
12:28 AM26/07/2016
The date should
be generated
automatically by
the repository
system and
recorded in the
YYYY-MM-DD
format.
48 of 56
recommended.
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
experience of
using the object in
a teaching and
learning situation.
9
9.1
classificati This category
describes where this
on
learning object falls
within a particular
classification system.
The purpose of
purpose
classifying this
learning object.
O
Classification may O
be used for
multiple puposes.
The UK LOM Core
recommends the
following usage at
present.
discipline - formal
subject
classification or
idenification in use
by the institution
or sector. E.g.
National
Curriculum 5-14
http://www.nc.uk.n
et/home.html,
learndirect Subject
Classification
(Levels 1-2)
http://www.learndir
ectadvice.co.uk/provi
der/standardsandc
lassifications/class
page/, Joint
Academic Coding
System
http://www.hesa.a
c.uk/jacs/complete
classification.htm,
Dewey Decimal
Classification
(Summary Levels
1-2)
http://www.oclc.or
g/dewey/about/dd
c_21_summaries.
htm.
12:28 AM26/07/2016
49 of 56
For purpose, value
of ‘discipline’, see
Appendix F of COSE
manual
3+
recommended.
typically this would
have value of
‘discipline’ but nodes
for other purposes
could be added
in addition
could be system
generated (for
‘discipline’)
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
idea - relates to
the concept
contained in the
resource. It is
possible to use
vocabularies
already used for
Discipline but to a
deeper level e.g.
LDSC, DDC.
Other excamples
include subject
specific
vocabularies e.g.
MESH
http://www.nlm.nih
.gov/mesh/meshh
ome.html
accessibility
restrictions - no
suitable
vocabulary exists
at present.
educational level the
cognitive/grade
level for which the
resource is
intended. It is
recommended
that the Scottish
Credit and
Qualifications
Framework
http://www.ngflsco
tland.gov.uk/nq/cq
framework.asp
should be used as
a common spine.
See Appendix 2
for a draft
mapping between
the SCQF and
other UK
qualification
12:28 AM26/07/2016
50 of 56
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
Technical Report and Update
Eleme Element
nt
Name
Numb
er
Explanation
UK LOM Core
Implementation
Guidelines
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
3+
recommended.
frameworks.
9.2
9.2.1
9.2.2
taxon path A taxonomic path in a
specific classification
system. Each
succeeding level is a
refinement in the
definition of the
preceding level.
There may be different
paths, in the same or
different
classifications, which
describe the same
characteristic.
The name of the
source
classification system.
This data element may
use any recognized
"official" taxonomy or
any user-defined
taxonomy.
A particular term within
taxon
a taxonomy. A taxon
is a node that has a
defined label or term.
A taxon may also have
an alphanumeric
designation or
identifier for
standardized
reference. Either or
both the label and the
entry may be used to
designate a particular
taxon.
9.2.2.1 id
9.2.2.2 entry
9.3
O
Where possible
use a vocabulary
that is already in
common usage
e.g. DDC, LDSC,
MESH.
O
could be system
generated (for
‘discipline’) as
‘DDC’
O
3+
The identifier of the
taxon, such as a
number or letter
combination provided
by the source of the
taxonomy.
Use a notation or O
classmark from
the chosen
classification
scheme described
by 9.2.1 source.
3+
The textual label of the
taxon.
Use a term from
O
the chosen
classification
scheme described
by 9.2.1 source.
3+
For ‘discipline’ and
‘DDC’ and ‘579’,
value could be
‘Microorganisms, fungi,
algae’
O
3+
recommended
description This is the description
of the learning object
relative to the stated
9.1:Classification.
Purpose of this
12:28 AM26/07/2016
recommended
for ‘discipline’ and ‘DDC’,
value could be e.g. ‘579’
free form textual
description
51 of 56
Technical Report and Update
Eleme Element
nt
Name
Numb
er
9.4
keyword
Explanation
UK LOM Core
Implementation
Guidelines
specific classification,
such as discipline,
idea, skill level,
educational objective,
etc.
These are the
keywords and phrases
descriptive of the
learning object relative
to the stated
9.1:Classification.Purp
ose of this specific
classification, such as
accessibility, security
level, etc., most
relevant first.
12:28 AM26/07/2016
52 of 56
UK
LOM
Core
Use
COSE
level*
COSE Implementation
Notes
O
3+
multiple keywords
allowed. add as
new nodes in RELOAD
rather than as semi-colon
separated list
Technical Report and Update
Appendix E: ICE COSE Technical Modifications Plan
Technical Task
1.1
Notes
Submit search and parse o
results
For ebrary and Emerald:
o
Search field mapping
o
Search query
construction and
submission
o
Results parsing to
create RRO
o
Add RRO to list in
search tools
o
o
o
Status
Require search tools
o
field mapping - to fit
search methodology of
o
each aggregator
Ebrary – commn’s only
through authorised
servers => servlet
o
handler/container =>
investigate/implement
‘Tomcat’ (Sun
o
recommended)
Emerald – doesn’t
o
return XML. Must
parse HTML for results
facility to select RRO
and browse via
browser window
dependent on ‘Browse
RRO’ task below
Tomcat
installed
Search field
mappings done
for both ebrary
and Emerald
Search queries
constructed and
submitted
Ebrary results
can be parsed
RROs searched
and returned in
search list
Milestone 1 – can search agg/pubs and parse results (know data returned)
2.1
2.2
Save RROs in basket
o
select RRO(s) from
results list
o
copy
o
paste into basket
o
saving basket saves
(creates) the RROs
Save RROs
component
in
select RRO(s) from
results list
o
copy
o
paste into index comp
o
saving index comp
saves the RRO refs in
Allow user added/edit
metadata at this
stage?
o
RRO will be saved as
pasted into basket.
Confirmed.
o
ability to save depends
on having relevant file
structures and format
in place- see XML
database below
index o
o
12:28 AM26/07/2016
o
need to allow user to
enter own url and
save this.
53 of 56
o
RROs copied
and pasted to
basket (already
saved);
metadata
editable;/
viewable
o
RROs created /
saved in
component
editor
Target
Date
Technical Report and Update
the index component
and creates the RRO
2.3
XML ‘database’ to store
metadata
o
RRO metadata
saved as xml
o
can edit RRO
metadata; stage
1 and 2 input
not yet
implemented
o
In generating
RRO these are
normal
functions of the
component
editor – check
is case (title,
keywords)
o
Bigger job is
modifying
COSE Editor
+ changes to format of idx
files etc
Milestone 2 – can save the RROs as independent COSE objects
3.1
3.1
Edit RRO metadata – new o
interface phase 1
o
integration of reload
o
‘advanced’ (edit all) +
o
+ stage 1-3 view/edit
investigate integration
of reload. metadata
frame only if possible
<= simple interface
Edit RRO
o
change title
o
change launched in
own window or not
o
edit metadata
Milestone 3 – metadata edit/add/view interface prototype developed
4.1
Edit index component
o
4.2
o
looks OK
o
looks OK
Add/remove/change
order of RROs and
other objects
Browse index component
o
select index comp in
browse tree or alone
o
browse
o
browser reads index
comp, old and new
format entries
o
RROs and other index
comp entries shown in
tree on left
o
selected RRO/other
12:28 AM26/07/2016
o
This task needs to
address old and new
index component
formats?
54 of 56
Technical Report and Update
item launched in RHS
pane
4.3
4.4
o
Browse RRO
o
select RRO in index
comp or via search
o
browse
o
RRO icon and title in
left pane
o
RRO launched via
appropriate mechanism
in RHS pane
Included explicitly
o
because of need to
‘fire’ for e.g. edf servlet
(ebrary) to launch doc
viewer
Copy RRO from index comp /
basket to basket / index comp
o
select RRO from index
comp
o
copy
o
paste in basket
o
RRO not created
afresh, only ref saved
RRO ref can be
viewed on its
own and as ref
in index
component
o
looks OK
o
not done
Milestone 4 - can manipulate RROs as other COSE objects
5.1
Review new
interface’
‘metadata
o
decision on use
throughout stages 1-5
o
address integration of
new metadata
implementation and
vestiges of existing
export facility
Milestone 5 – a consistent approach to view/add/edit metadata agreed
6.1
Edit RRO metadata – new o
interface phase 2
o
stage 4 view/edit
o
stage 5 view/edit
consistency re other
COSE components?
o
RELOAD
integrated only
for unpublished
RROs as yet.
Need to decide
on issues re
input at stages
4 and 5
Milestone 6 – COSE-wide consistent approach to view/add/edit metadata implemented/able
7.1
o
Publish index component
12:28 AM26/07/2016
55 of 56
There may be
Technical Report and Update
7.2
o
read RROs and other
items
o
publish RROs in same
manner as other COSE
comps
o
do something with the
metadata
Export index component
o
o
tutor - submit to
supertutor for export
and enter appropriate
metadata
no time to
incorporate
this. Enable
re-useability
in the
meantime
through
sharing?
o
Will this metadata get
cascaded to all
components?
o
Beyond scope of this
project (now)?
o
supertutor – export
requests – submit to
admin – add metadata
as appropriate
Index
components
with RROs - not
done. decision
required where
authentication
issues arise ?
impact of RLI
Milestone 7 – can publish and export RROs with metadata
8.1
Search within COSE for o
RROs
pro tem, upgrade
o
existing script / COSE
search facility – to use
enhanced metadata
o
enter search criteria
o
search within COSE
o
Lucene??
o
add results to results
list
o
resulting RROs have
already been created
and so don't need
saving again
o
toggle button for
searching on
enhanced metadata
not done
Milestone 8 – can search in COSE for RROs
9.1
User
tuning/polishing
interface o
new RRO icon – if time o
End project
12:28 AM26/07/2016
56 of 56
not done