DLXS notes
From openmichigan
Revision as of 12:23, 20 October 2011
John was very helpful in answering our questions about the UM Library's creation and use of DLXS image and text classes. First of all, I will lay out the immediate drawbacks of DLXS:
- No web services API - nor is there a way to upload batches of content to the system through a web interface. Content and separate metadata must be handed off to system admins.
- Access management is difficult at the sub-record level (content object level). Hard to do fine-grained ACLs.
- No full-text indexing of documents - SQL database queries of large blocks of text stored in metadata fields.
- Flat hierarchy structure results in some small limitations of content clustering/organization.
- No video streaming capabilities (can link to a streaming server).
- While software is free, we can choose to pay UM Libraries $5k/year for support (not sure what we get out of this support and this might be a human bottleneck).
DLXS is a middleware repository platform for storing and delivering content through a web interface. It works with a diverse set of databases storing a variety of file types. It can accommodate different metadata standards and offers mappings to the Dublin Core metadata set. DLXS uses a pretty flat (2-tiered) hierarchy system for storing content (record; sub-record), but with some effort it can accommodate another level of content. We were interested in how it would handle PowerPoint presentations, the context or slide images, and the content objects (images) within those slide images. This appears to be possible. This datastore seems to be robust and well-used, though it's unclear what the main advantages are from defining our own database scheme complete with pointers to a file repository. The system does not handle full-text indexing of documents and it does not have any built-in search functionality. It used to use the XPAT search engine (with a steep price-tag) but now uses a simpler SQL query set. In the meeting we asked why John did not use BlueStream instead of creating DLXS. His response was that BS stored content with no interest in long-term storage. I'm not sure what DLXS does to remedy this problem (Deep Blue, for instance, deals with service levels for preservation and persistent URLs). Also, BS is focused on providing content to UM users - those who have a uniqname for logging into the system. They are not concerned about providing content delivery to the general public. BS does provide web services for pulling content from BlueStream, but the definitions passed through this service are extremely limited (see BlueStream notes for more information).