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