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