Core Integration
CI: If all these things happened, what would we do with it
Public way for people to register candidate collections; it becomes part of a collection development
workflow; potentiall becomes part of the context creation workflow (tagging services, RDF triple-
based services); could turn around and do the overlay thing:
Value for others is that it's an easy way to have collections represented in NSDL; documents publicly
what's aggregated in the library; downside is it would be a visible workflow, so rejected collections
would be visible as well
Would be helpful to expose, would be helpful to screen candidates
David: what do we say about quality control in this instance
Questions for the group: how do we feel about the open-ness of quality control; what to do if
something is rejected?
CI could provide this information that other people could build on
SG: see lots of informational services provided by Pathways; is it incumbent on CI to provide a
transactional service to facilitate all of this information?
Dean's response: someone gives us a URL, we give them a chunk of information about it;
David: quality is huge and we need to bring this up; Dean: authority is also critical
Services to Link OpenCourseWare Repositories to the NSDL
What would we do with this?
We need access to metadata (as an intermediate step to the content) and content from selected collections and pathways in NSDL to build a content-based recommender system to relate resources to courses and vice versa. To do this we need metadata records on the resource, a URI for the resource and the content of the resource itself.
What do we want out of the registry or what we want the registry to do?
o Simple, easy, widely used (as in by the "real world", RSS, atom, whatever) or a toolkit or the like
o Query against registry returns
In addition to the collections, we'd like to see the following entries in the registry:
o Detailed list of services available from CI
o 10-20 services from Pathways, Services, Targeted Research grants (e.g ., General Recommender Engine, Instructional Architect, etc.)
Recommender Project
a. how useful would such a registry be to GRE?
1. Assuming such registry has every piece of information we need from a
collection (or a service),
GRE can use the registry to decide who our partners might be.
2. We would know what additional effort is required to integrate with a
particular service,
e.g. for some collections, we might need to develop a program to generate
"audience level"
information for each document, in order for knowledge-based engine to
generate
recommendations.
3. We would know where to obtain the data/document/metadata from we need to
provide services, e.g.
the location of their collections and metadata (if not available in the NSDL
metadata repository).
4. We would know what other services might have the functions we need, e.g.
community single
sign-on, to identify a particular user for collaborative filtering.
5. If a collection gives out information about their user population, we can
tune our engines
accordingly to provide more accurate recommendations.
6. Advertising by-products of our services, e.g. audience-level info our
program generates
for documents, or like-minded user groups that we identify. (Note: we don't
want to register every
single function of our system because making them available separately adds
to the complexity
of maintenance. However, we are more than happy to provide by-products that
might be useful to other
collections or services, once they are available.)
b. what does GRE want out of this?
1. We want easier integration – meaning by using the information from the
registry, we can
easily identify collections that we can easily integrate with. (If we had
that, we would
not have asked DLESE to be a partner, for their user clickstreams are harder
to track.)
2. Identify other services or collections which need the same kinds of data
to develop standards
for them, e.g. clickstreams.
Emory University
Emory/My interest in the registry
1. I am very interested in the notion of making superimposed/value-added
information available for harvesting and re-use. Examples of this type of
information are commentary (scholia); judgments such as ratings, reviews, and
vetting clearances; or folksonomic connections and interrelations (including to
people). This information could then be harvested by third parties to bolster
information retrieval, help guide navigation aspects of user interfaces
(navigate to related things), or do routing of related information.
This bears on a number of projects I'm involved with, including Quality Metrics
(which seeks to improve retrieval interfaces through value-added/quality
information about DL artifacts) and PlanetMath (where we seek to provide
linkages between relevant free/open mathematical sciences resources (such as
linking, or connections based on works derived from each other).
2. At Emory we're also very interested in transformation services (which we've
described in the context of the OXF paradigm). In the context of shared
library information, collection building involves gathering and numerous
(likely iterative) refinement steps. On the MetaCombine, we developed many
such refinement techniques and systems, and noted that others had developed
more. We would like to componentize and share our own services to refine
collections, and make use of those others have developed. We and others could
do this more easily if these refinement routines were in a service registry,
identifiable as routes that could refine or enhance individual records or
entire collections, and could be "pipelineable" together to perform more
advanced collection preparation.
Examples of refinement and enhancement steps include classification (deriving
subject tags), clustering (doing the previous without a pre-existing
classification scheme), date and other field normalization, geocoding, deriving
additional helpful metadata like thumbnails or collection-level metadata, and
much more.
SKOLR / ARLO
To be added...