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

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

Florian,

Thanks for the information.  

On your points:

>There are client libraries for many programming languages today that make
>the bindings (almost) transparent to a developer. A developer uses the API
>of the client library and eventually only needs to learn the domain model.

This is the 'chicken and egg' situation.  Not enough of the DAM vendors I
speak to (from small through to relatively large ones) are willing to invest
the time to integrate with these libraries.  You can argue that they should,
but if no one is either asking for it nor telling them to do it then it
probably won't happen. CMIS is going to have to move to make it easier for
DAM vendors to create CMIS compliant data (via this sub-standard we are
seeking to establish).

The document type might be the way forward:

>For example, a DAM profile could define that a server must provide a type
>"dam:asset" that is derived from "cmis:document" (section 2.1.4). It would
>inherit the properties of "cmis:document" and add new DAM specific
>properties. The profile could also define that all objects that carry
>content must be of the type "dam:asset" or a type derived from that

The way I'm seeing this working is that we define a document type which DAM
systems can populate, with some sub-extensions for various other metadata
standards that might be required (IPTC, PLUS, Dublin Core etc).  The
DAM-CMIS compliant DAM vendor needs to be able to generate data that adheres
to this standard and any metadata extensions they are interested in.  

If they want to read metadata from third party applications, then it might
be more reasonable that they have to get to grips with a CMIS library - but
presumably, they're doing that because they have a requirement from a
customer who wants them to access CMIS data and, hence, there is a need to
motivate them to find out more anyway.

In my mind, the CMIS-DAM compliant type could be generated as a pure RDFa
Linked Data object you can get to via http also - with or without a library.
So there are two ways - via CMIS libraries to retain access to the superior
facilities available in the rest of the CMIS protocol (including ICOM etc)
and also a more direct route via RDFa.  If sufficient DAM vendors can be
persuaded to use the simpler model and we interface that to CMIS, then their
data acquires at least partial CMIS compliance without them needing to do
very much (and we'll gain far greater levels of adoption in DAM as a result
- albeit at a fairly rudimentary level).

All that said, I'm talking hypothetical objectives, you are describing facts
about CMIS. The task is how to connect the two and I fully accept that some
of this may exist already - in which case, the process is more education
oriented than defining new sub-protocols.  We shall see to what extent that
is (or is not) the case!

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 Mueller,
Florian
Sent: 01 November 2013 21:11
To: ralph@daydream.co.uk; dam-cmis-profile-discuss@lists.oasis-open.org
Subject: Re: [dam-cmis-profile-discuss] RE: Key Objectives For CMIS/DAM

Let me try to explain the CMIS 1.1 specification in a few sentences.

The CMIS specification is divided into two parts. The first part describes
the domain model (chapter 2) and the second part the bindings (chapters 3,
4, and 5). 

The domain model defines the six base types (document, folder,
relationship, policy, item, and secondary), their metadata and their
behavior (section 2.1). It also describes all CMIS operations (50+)
(section 2.2). The domain model does not say how a client and a server
communicate, though.

The CMIS bindings chapters define how the domain model is mapped to the
bytes on the wire. CMIS 1.1 defines three bindings:
- The Web Services binding, based on SOAP (chapter 3)
- The AtomPub binding, based on the Atom specification (chapter 4)
- The Browser binding, based on JSON and form data for JavaScript
applications in a web browsers (chapter 5)

The bindings are equivalent and a client can choose the binding that works
best in its environment. (There are only a few minor things you can't do
with the AtomPub binding.)
There are client libraries for many programming languages today that make
the bindings (almost) transparent to a developer. A developer uses the API
of the client library and eventually only needs to learn the domain model.

The domain model defines a set of mandatory data structures and operations
and several optional capabilities. A client can ask for the so-called
"repository info" to determine which capabilities the server provides.
The repository info has an extension point that would allow exposing
profile information. For example, a DAM server could provide information
about the DAM profile it supports and DAM specific capabilities. A DAM
client would be able to determine if the server supports the feature set
it needs.

A CMIS server is not allowed to expose another (seventh) base type, but it
can provide a hierarchy of types derived from the six CMIS base types.
These types can add more properties and may have a different behavior than
the parent type.
For example, a DAM profile could define that a server must provide a type
"dam:asset" that is derived from "cmis:document" (section 2.1.4). It would
inherit the properties of "cmis:document" and add new DAM specific
properties. The profile could also define that all objects that carry
content must be of the type "dam:asset" or a type derived from that. A
pure "cmis:document" object wouldn't exist in such a repository. The
repository would still be CMIS compliant and generic CMIS clients could
work with it.

I don't think there is anything to simplify if you start with the
mandatory CMIS capabilities and build the DAM features on top. Also the
Browser binding is a very simple and lean wire protocol. Find a few
examples here: [1]


I hope that helps,

Florian


[1] http://docs.oasis-open.org/cmis/CMIS/v1.1/os/examples/browser/






On 01.11.13 10:31, "Ralph Windsor" <ralph@daydream.co.uk> wrote:

>On point (1) of my message from last week, it seems to me that the
>cornerstone of any simplified variant of the CMIS protocol for DAM is a
>definition of the Objects to be stored (which are probably the assets in a
>typical DAM system in the vast majority of cases).  This should describe
>the
>core essential object properties which any compliant DAM systems need to
>be
>able to generate to allow more fully CMIS compliant tools to interpret
>them.
>
>I lack a full grasp of the CMIS protocol, is anyone on the list able to
>explain, in basic terms, how this works in CMIS and also cite any relevant
>sections from the CMIS spec?
>
>We'll almost certainly need to extend this with compatibility mappings
>between other protocols, but they can all come in later.  Right now, it's
>the real 'need to know' stuff we should  be interested in.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail:
>dam-cmis-profile-discuss-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail:
>dam-cmis-profile-discuss-help@lists.oasis-open.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail:
dam-cmis-profile-discuss-unsubscribe@lists.oasis-open.org
For additional commands, e-mail:
dam-cmis-profile-discuss-help@lists.oasis-open.org