Dec 28, 2002
James M. Nugent wrote, "I concede, though, that if one could come up with a model that would allow for fair compensation for RLO creation using the Web accessibility model, then the need for RLO libraries everywhere would not exist, and in fact would be a waste of money if RLOs were that easily obtainable."
Right. Please allow me a few paragraphs to explain how this will work in a distributed learning object repository model (notice that I say "will" work - this is how it's going to happen).
Let us begin with a view of the world of learning objects - or learning resources generally, since I don't want to be pegged into someone's narrow definition - as a set of distributed resources, stored on provider web servers and distributed using many of the same mechanisms as web pages (or any other online resource, like PDFs, MS Word documents, streaming media, chat rooms and discussion boards...)
Let us also assume that there is a reliable mechanism (which I describe elsewhere) for locating these learning objects, that a metadata-enabled 'Google' and 'Alta Vista' of learning objects exists, and that instructors and developers can locate precise lists of learning objects for very specific purposes.
There then remain three problems facing the creation of a "model that would allow for fair compensation" for the use of learning resources:
1. How to ask for payment (and to specify use conditions)
2. How to actually make the payment, and
3. How to make delivery of the learning resource contingent on the payment.
Let us look at each of these in turn:
1. How to ask for payment (and to specify use conditions)
On the world wide web, there is no means to ask for payment, at least, no means to ask for payment for a specific resource without a long and cumbersome procedure. This is why most fee based web sites ask you sign up for a subscription that will allow you access to all their contents. And in those cases where you can access single articles, a ridiculous charge (five dollars for a newspaper article, thirty dollars for a journal article) is imposed (and you still have to go through the process of entering your credit card information).
In the world of metadata, however, we can make this much simpler, since every learning resource has its own metadata (and indeed is located using this metadata).
So, suppose you are a learning resource provider and you wish to charge for your learning resource (and perhaps impose other conditions, such as an expiry date for use, print rights, et cetera).
In your learning object metadata you create a bit of metadata referring to what may be called a DRM model. Like this:
The broker is an organization that specializes in selling learning resources. Larger agencies may act as their own brokers. Small and poor learning resource providers (like me, acting as an independent provider) would contract stand-alone brokers.
The broker provides a set of DRM models stored as metadata on its website. The 'Easy page One' specified in the example above is one such model. Essentially, this model is an XML file specifying a set of rights and conditions, including the cost to use this resource. The model metadata may look (in part) like this:
(Please note that all metadata in this post is simplified for the purposes of explanation)
A variety of schemas already exists for the creation of metadata files describing digital rights. There is, for example, XrML, a rights management language sponsored by OASIS. There is ODRL, an open digital rights markup language. The IEEE-LTSC is working on a rights model specific to educational purposes.
Links:
XrML: http://www.xrml.org/
ODRL: http://odrl.net/
IEEE-LTSC: http://xml.coverpages.org/DREL-DraftREL.pdf
It is worth nothing that something like this is very much the model being adopted by the Creative Commons project. The purpose of Creative Commons is to provide an easy mechanism to allow people to share their online content for free. A variety of options exists: a content provider may wish to allow or disallow commercial use, a provider may wish to require or not require attribution, et cetera.
Creative Commons has created a set of template licenses, one to describe each possible combination of licenses for free content distribution. In order to use one of these licenses, a provider of web content needs merely to link to the appropriate license on their web page. A potential user then accesses the license and decides whether or not their use is allowed by the conditions in the license.
Link:
Creative Commons: http://www.creativecommons.org/
To add to this: Creative Commons also provides a licensing wizard that allows a content provider to make a set of selections (using an easy forms-based menu). Once the selections are made, Creative Commons automatically generates the (HTML) code required in order to apply a certain sort of license. This means that content providers do not actually need to know anything about the code describing the license; they simply cut and paste from the code provided.
This sort of mechanism is easily applied to XML. Moreover, since the wizard is available online, this sort of mechanism may easily be provided via a web service into a content creation tool. This allows the entire process of creating appropriate licensing metadata to be automated, making it a trivial task or content developers.
The major advantage of using third parties to supply metadata licensing will be evident below. But for now, some advantages are already clear. First, it means that content providers are not tied to any particular rights management schema. This is important to allow compatibility between commercial and non-commercial providers.
For example, some rights management languages may require the payment of a royalty for use. This was one of the major fears about XrML, which was developed by a private company (Content Guard). Requiring the payment of a royalty would make it much more difficult to provide learning resources at low cost or for free, and so a system that depended on one sort of rights markup language would effectively split the market into two.
The use of rights management models (rather than, say, embedding rights management information into learning object metadata) becomes apparent when the task of changing licensing conditions comes up. In order to raise (or lower) a price, for example, only a single file need be edited, as opposed to the metadata for every learning resource provided.
2. How to actually make the payment
The next step of the process occurs when a learning object is presented for consideration for use. When some material is actually selected, then (if required) the payment mechanism should kick in and facilitate the transaction.
A brief consideration of the payment mechanism shows that this is a complex process, one that has never been solved to anyone's satisfaction. The usual method at this point is to present the user with a credit card screen, a process that becomes tiresome very quickly. Alternative mechanisms require the presentation of a password, licensing information, and even IP authentication (sometimes via a proxy server).
A variety of approaches are possible here, but the approach that will eventually be adopted is the one that provides several key features for potential users:
- Control over the presentation of options
- Trust in the payment mechanism
- Ease of making payment
For the content provider, several other requirements come into play:
- Actual receipt of payment in real time
- Trust that the copyright conditions will be observed
Additionally, various stakeholders have a number of ancillary interests. Such stakeholders could include school boards or ministries of education, employers, professional associations, parents, and other service providers. These stakeholders want mechanisms to:
- Influence the selection of resources for selection
- Pay for resources on behalf of users via licenses or subscriptions
- Track the use of learning resources
Consideration of the requirements posed by these groups leads us to the following set of steps involved in actually paying for learning objects:
A. Presentation of a list of resources
B. Selection of a resource and retrieval of digital rights information
C. Generation of a request for the learning resource
D. Granting of the request for the learning resource
Let's look at each of these in turn.
A. Presentation of a list of resources
i. Via Search Results
The first step in the process is the presentation of a list of resources for the user's consideration. This presentation can occur in a variety of ways. The prototypical mechanism exists when the user conducts a search from a metadata repository (the 'Google' of learning objects) and is presented with a series of results.
In such a situation, the user generates a search request to the metadata repository. The search request may specify the usual parameters, such as the topic under consideration, the granularity of the object being sought, or the format or medium under consideration.
From a digital rights point of view, the user should also be able to specify the rights models that will be acceptable. For example, if the person is cheap (like me) then they will not want to view any object that requires a payment. Or perhaps a person is willing to accept a payment, but only up to a certain amount.
Because the digital right model is specified in the learning resource metadata, it is easy for the metadata repository to learn the conditions associated with each learning resource in its index. It is thus easy for the metadata repository to filter the list of resources provided according to the rights management conditions placed in the search.
Typically the user would store these conditions as part of a default set of parameters designed to accompany any search. This default set would either be attached automatically or selected en masse via the selection of a profile (eg., 'at work' versus 'at home'). Typically, the user would identify only the topic desired (either via a keyword, search string, or predefined classification schema obtained using a web service). The remaining parameters - age level, modality, rights management, et cetera - would be added to the search request automatically.
It is at this point that third party stipulations would be incorporated into the search. Depending on the profile selected, an employer's recommendations may be added. The employer may limit the selection to a specific list of providers (for which it has content licenses, say, or for which it has granted accreditation).
In order to make such a mechanism work, a variety of systems need to be in place. I will address the major components in turn.
a. User Profiles
A given user needs to have a predefined profile containing relevant information. The user profile is stored as a metadata file and contains the usual information (name, address, age) along with the data required to enable the search process.
Various user profile metadata schemas already exist. Microsoft's Passport, for example, stores user metadata according to a 'Passport Profile Schema' (which, unfortunately, doesn't appear to be available for general viewing). A variety of different approaches may be found by searching on Google for personal.xsd.
Link:
http://cml.sourceforge.net/schema/STMML/EXAMPLES/PERSONAL.XSD
Today, user profiles have been associated with specific applications or services. While this trend may continue for the short-term, over the long term we should expect to see the provision of personal profile services on the web. This allows users to create and use a vendor-neutral (and institution-neutral) description of themselves.
Inside the personal profile are various sub-profiles, indicating different contexts of use. For example, a person's personal profile may specify different attributes while 'at work' or 'at home':
Within the personal profile is the search information to be sent to the metadata repository. Additionally, within each subprofile is additional search information.
Just as in the case of rights management (described above), the reference is to a metadata file stored on the employer's website. This metadata file contains a list of recommendations and permissions to be applied during the search for learning resources. Just so, a set of recommendations and permissions could be specified by school boards, parents, educational funders and other third parties.
b. Profile Servers
A user profile server is a stand-alone application that releases bits of a person's user profile to external service on request and according to user-specified permissions. Several different models exist.
One alternative is to have a computer-based profile server. The personal profile is stored on the user's computer. It is added to by means of profile wizards and also as a consequence of program output (for example, when you install ICQ, it may seek to add your ICQ number to your personal profile). When computer programs and web services request profile information, then the information is released according to a set of rules (including allowing everyone to see some things, requiring a popup permission to be displayed for others, and refusing ever to allow still other information to be released).
The weakness of this approach is that it is specific to a specific computer. Thus, a person who (like the vast majority of us) uses more than one computer would find this approach unsatisfactory.
A second alternative is to place profiles on service providers' computers. This is in fact what happens in most cases today. At each service a person uses (the government, a university, Amazon.Com, Microsoft Passport) a separate profile is created. This profile may be accessed by entering a password.
The problem with this approach is that for each new service a person uses, a separate profile must be created. This makes updating profiles an impossible task, leading to misinformation in separate profiles. Additionally, the information (with some exceptions provided by Passport or Shibboleth) is not portable.
An even larger problem exists with control over the personal information provided. Though online service providers frequently promise never to share personal information, the volume of email spam proves that such promises are hollow. Moreover, control (and even ownership) of the information lies in the hands of the service provider.
The third alternative is preferred: the development of stand-alone profile management services that act as a broker for personal information on the internet. Because many such services exist, a person can choose a local and trusted broker (one they can sue if things go wrong). Because such services are working on behalf of the user (and may be paid for by the user, though no doubt free brokers will exists as a public service) there is no vested interest in ownership of the information: it is to the broker's advantage to ensure that the user owns his or her information.
A stand-alone personal information broker may also provide the security of information third parties often require. 'Read-only' information, such as grade transcripts, certifications, and the like, may be accepted (with the user's permission) by stand-alone brokers. Thus, these stand-alone brokers may be trusted not only by the user, but also by third party applications seeking to obtain information.
Links: I can find almost nothing on this, except for:
Microsoft Passport: http://www.microsoft.com/netservices/passport/
Shibboleth: http://shibboleth.internet2.edu/
c. Creating and Sending the Search Request
The search tool employed by the user (either a specialized learning objects browser (LOB) resident on the user's desktop, or a service available online (such as a learning content management system), now gathers the search information. It may obtain search parameters from:
- the search request form filled out by the user
- the user's personal profile (with subprofile specified)
- third parties specified in the user's profile
This information is parse by the search tool and organized into a search request format. The search is conducted using XQuery and SOAP. This process is already well documented by the IMS consortium Digital Repositories Specification.
Link:
XQuery: http://www.w3.org/TR/xquery/
SOAP: http://www.w3.org/TR/SOAP/
IMS Digital Repositories Specification: http://www.imsproject.org/digitalrepositories/index.cfm
ii. Via Content Packages
Most accounts of online learning do not depict students searching for and retrieving a set of educational materials. Rather, they envision the creation of sets of prepackaged materials (structured, for example, into lessons and courses). This approach supposes that the searching, relevant annotation, and organizing has already been accomplished by an instructional designer or teacher (using much the same process as just described above).
Various accounts of learning content packaging exist. IMS, for example, described a package of learning objects using a manifest, an XML document describing the contents and organization of learning resources in the package. The IMS Simple Sequencing model can work with a manifest to control the display of learning resources according to input, test results, or other variable parameters. At a more tightly defined level of granularity, the Educational Modeling Language (EML) EML describes not just the content of a unit of study but also the roles, relations, interactions and activities of students and teachers.
Links:
IMS Content Packaging Information Model: http://www.imsglobal.org/content/ packaging/cpinfo10.html
IMS Simple Sequencing Information and Behavior Model:
http://www.imsglobal.org/simplesequencing/v1p0pd/imsss_infov1p0pd.html
EML: http://eml.ou.nl/
However the organization of the learning material is defined, whether by means of search results (described above) or via an intermediary mechanism as described in this section, there comes a point where the learning resource itself is presented to the user.
In many descriptions, when this moment occurs, the learning resource is already resident either in the student's computer (perhaps on a CD-ROM) or in the learning content management system. This presupposes that all DRM matters have been attended to: that the object has been licensed and paid for and made available for use. Thus the IMS Content Packaging Information Model explicitly allows for the location of "physical files" within the manifest.
On the model being described here, however, what has been obtained thus far is nothing more than a reference to the learning resource, and not the learning resource itself. Thus, manifests employed in the present system would not contain physical files (though they could be nearby, via a caching mechanism, should bandwidth be an issue).
Importantly, the learning resource has not necessarily been bought and paid for. Though prepayment and pre-licensing is an option, it is not a requirement. It is therefore possible for an instructor or an instructional designer to create and deliver a package of learning materials without having spent one minute obtaining rights and clearance.
This is a significant matter. As MIT's Jon Paul Potts admitted during a recent interview about their Open Courseware Project, the single largest expense was in the organization and acquisition of digital rights before placing course materials online.
Link:
Technology Source Interview: http://ull.horizonlive.com/launcher.cgi? channel=tsdownes1202_2002_1205_1404_20
A better example of this sort of approach is provided by XanEdu's Coursepack service. XanEdu allows teachers to login and view all learning content without charge. It also provides a wizard-like service to allow instructors to select learning resources for inclusion into a single resource called a webpack. On reading the coursepack, the student reads the instructor's annotations and is provided with links to the learning resource.
XanEdu's model requires that students create individual accounts with the service. When the student selects the resource for viewing, access to the resource is granted only to students with accounts. Each item added to the coursepack is priced individually, and the student is charged only for the materials accessed. The learning resource resides on XanEdu's server throughout this process, delivered to the student only at the time of request.
Link:
XanEdu Coursepacks: http://www.xanedu.com/coursepacks/
No matter how the list of resources is obtained - whether it be via a search process, a manifest, a sequencing mechanism or a course pack - the process is the same. A list of resource metadata, in XML, is presented to the viewing device. Then the viewing device interprets this list, either providing a set of links on which the learner may click, or automatically invoking a request for the learning resource.
The viewing device may be a stand-alone learning object browser. It may be a learning management system the student accesses via the web. It may be processed and sent as an email message providing a list of links. The resource itself - no matter what viewing device is used - remains on the provider's web server until a specific request is generated.
C. Generation of a request for the learning resource
On the world wide web, generating a request for a learning resource is straightforward. The resource is specified in a URL. The URL contains the location of the remote server and the file name for the specific resource. A connection is opened to the remote server and a request (HTTP-GET) is sent for the specific file. If the file exists and access is allowed, the server sends the file in response to the request. Then the connection is closed.
The problem with this mechanism is that there is no method for the payment for a given resource. Payment must be arranged through a separate transaction, and then that transaction must be authenticated (for example, by submitting a password) at the time of request. What is needed, therefore, is a means of combining the payment, authentication, and request for a resource.
In order to accomplish this, the device making the request must do the following:
- determine whether a payment is required
- enable a decision as to whether to approve the payment
- make the payment
- obtain the authentication needed to access the resource
i. Determination of whether a payment is required
Recall from above that the learning resource provider encoded a reference to a rights model in the learning resource metadata. This information may have been used in the search process. The reference is now available to the viewing device. Either the reference was included in the information contained in the original request, or it must be obtained via a request for the full learning resource metadata.
The viewing device is now able to determine whether a payment is required. Several possibilities exist:
- there may be no rights metadata, in which case the server may assume no payment is required
- the rights metadata may point to a service such as Creative Commons, in which case it may assume that no payment is required
- the rights metadata may refer to some other rights management service, in which case it needs more information
ii. Decision as to whether to approve the payment
If more information is required, the viewing device's next action is to retrieve the rights model from the rights broker. It is presented with the model, which it parses and extracts (minimally) the price (and unit of currency). It then compares this information to the information in the user profile and determines whether to:
- authorize payment automatically
- provide a yes/no option to opt for payment
- reject the request and send an error message
The third option is annoying, which is why it is important to filter such requests in the search process. The second option is also annoying, and should be used only to flag extreme cases (such as when an individual item cost breaks a threshold, or when total spending crosses a threshold).
Whether the first option (automatic payment) is the case, or whether the user selects 'yes' for the second option, at this point a payment must be made.
Typically at this point credit card, subscription or license information would be sent to the resource provider. However, this is an approach fraught with pitfalls:
- it requires that the viewing device be able to send any combination (and only the correct combination) of licensing, subscription or credit card information
- and do it securely
- it requires that the resource provider be able to process such information
- and do it securely, in such a way that the user trusts the service provider
Making the Payment
We have already seen (above) where a learning resource provider relies on a third party to manage rights models metadata.
It is already common on the world wide web for service providers to contract third parties to receive payments on their behalf as well. Examples of such services include Cardservice, PSIGate, WorldPay, and more. Such services (for a price) minimize the overhead required for an online merchant to set up shop.
Links:
Cardservice: http://www.cardservice.com/
PSIGate: http://www.bluegenesis.com/psigate.html
WorldPay: http://www.worldpay.com/
Payment Gateways: http://www.multiactive.com/solutions/ecbuilder/gateway.html
Such services, however, do not provide a wide range of options for the purchaser. What is needed is an analogous service, one that represents the purchaser, and which makes payments to the content provider (or content provider's broker) on his or her behalf.
The purchaser broker is a service very similar to the personal profile management service (it may even be the same service).
The location of the purchaser broker is contained in the personal profile and is made available to the viewing device. When a payment is required, the viewing device sends a request to the purchaser broker. This request is a simple metadata document containing the rights management information contained in the learning resource metadata and the user's purchaser broker information as obtained from the personal profile.
The purchaser broker maintains an account on behalf of the purchaser (much like a bank account or credit account). The purchasing agent also manages subscriptions or licenses for the purchaser. When the purchaser broker receives a request, it:
- compares the request to licenses and subscriptions
- compares the request to conditions specified in the personal profile
- scans for anomalous requests
If a cash transaction or authentication is required, the purchaser broker sends the required information to the provider broker. This transaction is executed over a secure network. The provider broker then sends back the authentication required for access to the learning material, which is in turn passed to the learning resource viewer.
iv. Obtaining Authorization
When a provider broker receives a request along with payment or license verification, it returns a key for access to the learning resource. The vendor broker may keep keys locally, or if greater security is required, it may request the vendor for a daily rotating key. This key is sent as a response to the purchaser broker and in turn passed to the viewer.
3. How to make delivery of the learning resource contingent on the payment
The viewer, key in hand, now sends a request (it could be as simple as an HTTP-GET request) to the learning resource provider. The key is provided as part of the request. If the key is correct, the resource is delivered to the viewer for viewing. If the key is incorrect, an error is returned.
The security mechanism can be as simple as an .htaccess with a password. What is significant here is that even though the protection may be simple, paying for access through a Purchaser Broker is a much simpler and cost-effective means of obtaining the resource than any other (non-legal) method.
Link:
.htaccess: http://www.webdeveloper.com/servers/servers_htaccess_magic.html
Some resource providers, fearful that their resources may be copied and sent to third parties, may also elect to lock the document itself. This capability already exists for some document formats, such as Adobe's PDF format. Alternatively, content providers may wish to ship a locked viewer with the object. Once again, the key provided by the Provider Broker may unlock the document or document viewer.
Link:
Adobe 5.0: http://www.adobe.com/products/acrobat/pdfs/acroov.pdf
4. What Needs to Be Done
It seems to me that much more attention has been paid by the content industry toward preventing illegal access to online resources than to enabling legal access. But so long as the industry's focus is on security rather than sales, it will continue to founder.
Moreover, it also seems to me that what attention is being paid to content distribution on the web is being paid with an eye to being the sole (or "exclusively licensed") distributor of content to closed (read: academic) markets. But so long as more attention is paid to cornering the market rather than to building one, once again, the industry will continue to founder.
Most - if not all - of the knowledge needed to implement a learning content marketplace already exists. True, the description above is a bit fuzzy in places. How, for example, would a purchaser agent manage licenses? How, precisely, would a key open a locked document? But these are questions with answer, and many of the answers have already been developed. So: what needs to be done?
A. A Content Distribution Network
Part of the problem is that, aside from the world wide web, we do not have a content distribution network at all. We have points of access, such as the resource libraries hosted by traditional publishers. But these do not reach out to the wider market, and are so limiting in their access as to make them useless for educational purposes.
So we must first build the content network. We must build a network of learning resource providers who make their resource metadata available for harvesting. The model is in place: the OAI initiative provides tools and software to make this possible.
Link:
OAI: http://www.openarchives.org/
We also need metadata harvesters to aggregate this information and make it available for searching. Thus far, no such harvester exists: the only metadata repositories we have today depend on forms-based submission and lock their content away from prying eyes. But there are examples elsewhere: the RSS community has provided us with a great model for content harvesting and indexing.
Link:
RSS for Educational Developers: http://www.downes.ca/files/RSS_Educ.doc
Finally, we need learning content management systems and learning object browsers that look beyond their own internal repositories to search for learning resources. More than providing an interlibrary search, these systems should access proper metadata indexing services in order to locate learning materials for use in online courses, and then to be able to retrieve those resources for viewing.
These elements are coming. Indeed, they will be here faster than you think (though it may be a while before the large LCMS vendors cave and provide access to the wider marketplace).
B. The DRM Substructure
Once the content distribution network is in place, providing the DRM layer is almost trivial.
At the resource provider end, only one small tool is needed: a service that provides a key when presented with a proper request from a Provider Broker.
At the learning object viewer end, we need a mechanism that will make a request when presented with rights metadata stipulating that payment is required.
Finally, we need the two key players: the Purchaser Broker, and the Provider Broker. Instances of the services provided by these brokers already exist on the web. Payment processing agents already exist. And purchasing agents, while not deployed yet, exist in bits and pieces across the internet.
Nobody has shown any inclination to build such tools and make them available to anyone who wants to become a Purchaser or Provider Agent. Partially this is because they have seen no need - why create software for a network that doesn't exist? But partially it has also been greed: the people who have created these tools also intend to capture most or all of the commerce on the internet.
But it's not going to happen that way. It's not going to happen because nobody has a monopoly on sending and collecting money over the internet. It is - Microsoft to the contrary notwithstanding - not possible to create such a monopoly. Because even while it may be possible to have the only transaction system, it is impossible to close the door on the other alternatives: either the refusal of the population to conduct online transactions at all, or the redirection of such transactions to questionable or illegal underground services.
