Difference between revisions of "Metadata Retriever Plugins"
m (moved Metadata Importing Plugins to Metadata Retriever Plugins) |
(→Deferred until later) |
||
| Line 22: | Line 22: | ||
==Deferred until later== | ==Deferred until later== | ||
| − | Allow configuration of plug-ins | + | *Allow configuration of plug-ins |
| − | * | + | *Alter order in which plug-ins run (to determine which are authoritative) |
| − | |||
| − | |||
Revision as of 13:55, 17 June 2010
| Contact | Contact:: |
|---|---|
| Project | ,|project_name|Project Driver::project_name}} |
| Status | Status::In Development |
First Phase
Operators may wish to include metadata about Resources from other sources, including web services (ie, Semantic Analysis), databases, or something else. This describes how to implement a plugin to import this information.
A plugin implements IMetadataImporter, which provides a single method, loadMetadata. loadMetadata takes a Resource, and is responsible for adding any fields to it. loadMetadata is not responsible for persisting the Resource.
The initial prototype will log URLs as it goes.
The first working plug-in could exercise the del.icio.us API to retrieve tags that delicious users have placed on a URI. Example: api.del.icio.us /v1/posts/suggest?url=http://ocw.nd.edu/computer-applications/applied-multimedia-technology
To accomplish this...
- enable resources to allow dynamic metadata to be attached (by plug-ins) through a new method on "resource"
- method that adds an assertion to resource
- checks to see if the assertion exists, uses if exists, creates if not exist
- populates assertion with data
- method that adds an assertion to resource
-
- method that gets all the assertions from resource
- associate each custom metadata field with a URI-namespace to avoid cardinality
- Create plug-in; call from aggregate step; use resource's save method;
Deferred until later
- Allow configuration of plug-ins
- Alter order in which plug-ins run (to determine which are authoritative)
