Hi,
----- Original Message -----
> Hi Matt,
>
> The largest hurdle you would face with linked data and ContentDM are
> the
> inconsistently persistent URLs (to say nothing of the application
> specific
> jankyness in the url). When an item is added to a collection in
> ContentDM,
> it is assigned an ID which is used in the URL, ie
> http://digitalcollections.library.gsu.edu/cdm/singleitem/collection/ajc/id/805
> .
> However, if at a later point, you make a change to that item, say
> updating
> the OCR text, the item is given a new ID, and thus is accessed at a
> new
> URL.
This is not correct -- an item's ID (in CONTENTdm terms, its 'pointer') remains the same after an update to the item using the tools provided as part of CONTENTdm.
> However, the old URL does not redirect to the new one, it just
> dead
> ends, ironically at an error page with a 200 HTTP request status
> header!
> Wreaks havoc on search engines or any other system that relies on
> persistent URLs, as a Linked data system *may* want to do. :(
>
> That said, ContentDM 6 does have an API through which you can get
> data
> about any record. It's a little inconsistent, and the docs aren't
> amazing,
> but you can get most everything out of it that you'd want. So, if you
> had
> coordinates where and image was taken stored in a metadata field, you
> could
> use the API to get them and push that onto a Google map. So if you
> have a
> collection that is static, you probably don't have to worry about the
> URL
> borking feature they have included.
> More about the ContentDM API:
> http://www.contentdm.org/help6/custom/customize2f.asp
>
Dumping the data using the web-services API into LOD representations is definitely the way to go. CONTENTdm out of the box has no capacity to act as an LOD provider.
Mark
Received on Thu Feb 21 2013 - 11:13:40 EST