RE: [dam-cmis-profile-discuss] Key Objectives For CMIS/DAM

["Ralph Windsor" <ralph@daydream.co.uk>]

Hi Ray,

I thought that might be the case with the libraries.  If you're implementing
a full CMIS compliant app then I can see the benefit of them.  If you merely
need to integrate with one, they might be too onerous and your alternative
approach would be a good one for many.

On the goals question, these would be two starting points:

Must be compatible at a base level with the CMIS object (document?) entity
(mostly covered by your description)
Make it possible to define extensions as sub-schema, so that they can be
integrated (such as PLUS, IPTC, Dublin Core etc)

>Are we strictly talking about communication of binaries and metadata
between systems?

At this point, I would say 'yes' to that, as that's the first problem many
DAM users (and the consultants or vendors appointed to service their needs)
are experiencing.

> Do we expect to invoke some actions on a DAM server such as requesting the
transcoding of a video?  

That would be good to do eventually, but I think we're running before we're
walking if we try.  A common language for transcoding videos, or other asset
manipulation operations would be great, but it's actually even more than
just DAM vendors who would need to be bought on to achieve critical mass (in
terms of adoption) such as third party tool vendors.  

It sounds like the base level is defined by CMIS, but then we need some way
to add these specific sub-schemas into the mix.  Just the communications
part is going to be hard enough.  Defining schemas etc probably isn't the
complex element, it's getting people to use this stuff.  

Having said that, the fact of having an 'official' DAM-CMIS standard (that
is specifically for DAM - not just ECM) would massively help momentum.  DAM
is a 'me too' software fashion business where few genuinely innovate and
most vendors copy each other or follow trends.  If some start to use it and
put out PR about their adoption of it, then lots of others will start to
copy them to ensure they aren't getting left behind.

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/