[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dam-cmis-profile-discuss] Key Objectives For CMIS/DAM
Hi Ray (and others) Just to get this discussion activated again, one item that would be useful from my perspective (and possibly others from the DAM side of things) is an example of how CMIS object/document metadata is accessed via http but without using a library - as discussed in your message below. So, just using something very basic like curl or anything else that can issue http requests and display what is returned. If we had that, we can see then how you might define subsidiary definitions for various other common DAM metadata protocols and standards (IPTC etc). At the moment, the conversation is abstract and while we need to get objectives defined, we also need to connect this back to practical implementation issues as the latter will partly inform the former. I'm expecting that a decent amount of the groundwork for this standard will in fact be more about educating DAM developers, rather than defining a lot of new protocols or extensions thereof (although that will be required eventually). If anyone has a server and is able to set something like this up, that would be useful. As discussed, I don't want to do this with anything other than basic tools on the client end (although the server generating this could be more sophisticated). It's what kind of data a DAM developer interacting with CMIS data stores could expect to see. Anyone who is able to assist, please let me and the list know. Thanks, Ralph -----Original Message----- From: dam-cmis-profile-discuss@lists.oasis-open.org [mailto:dam-cmis-profile-discuss@lists.oasis-open.org] On Behalf Of Ray Gauss II Sent: 12 November 2013 12:00 To: dam-cmis-profile-discuss@lists.oasis-open.org Subject: Re: [dam-cmis-profile-discuss] Key Objectives For CMIS/DAM Hi Ralph and others, One thing to note regarding the perceived difficulty of implementation on the part of DAM vendors is that things like the Apache Chemistry libraries are by no means *required* for building a CMIS solution, they are simply a convenience. A server-side DAM vendor could choose to craft a response to a CMIS query however they see fit, provided the spec is obeyed. Similarly on the client side, an application is free to make an HTTP call directly to a CMIS server, without a library, via the browser binding (which returns standard JSON) and process that response. This is very much along the lines of what you described when you mentioned an RDFa solution. Regardless of the format/binding in which the data is passed between systems, both must marshall/unmarshall that data, and that is part of the convenience the libraries provide. The EIDR registry [1] for movie and television assets is similar to the PLUS registry, and those type of globally unique and agreed upon identifiers can be used in conjunction with repository-specific identifiers. I think we have done a good job outlining some of the technical possibilities of a DAM standard that could leverage CMIS, but have we skipped over defining the goals of such a standard? Are we strictly talking about communication of binaries and metadata between systems? If so a simple DAM profile dictating a specific data model would probably suffice. Do we expect to invoke some actions on a DAM server such as requesting the transcoding of a video? If so we're moving into defining the creating of renditions and the parameters of such a request, which, in that example, would include things like codecs, bit rate, resolution, etc. I'd love to hear from the group on some of the high level use cases we'd like to see addressed by this standard. Regards, Ray [1] http://eidr.org/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]