OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dam-cmis-profile-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi David,

 

Yes, a DAM server is a good idea and along the lines of what I had thought about.  I can foresee a need for direct communications still, however.  I’m envisaging at least two grades of compliance with DAM-CMIS: at a basic level it is going to be on trust and expectation that the counterparty is going to be following the rules.  This would at least get DAM developers on-board and is simple to implement even if it is lacking the benefits of a stricter method. 

 

Moving up a level, a DAM server could enforce (i.e. formalise) compliance.  That role could potentially be fulfilled by some of the asset registries, like PLUS (Picture Licensing Universal System): http://www.useplus.com/aboutplus/system.asp as they have contacts with many of the IP owners on the image side of things.  I’m not aware of anything similar for other asset types (e.g. video) but I’m willing to believe that if they don’t exist already, someone, somewhere is currently thinking they should.  Asset registries would need to be a party to this DAM-CMIS standard too (I know representatives of PLUS were on the call).

 

An issue with sensitive assets (or even those just for internal use only) is whether the controllers of those assets would want details of them exchanged with a third party, such as PLUS.  However, if there is an internal-only variant of this which uses this same standard (like an internal DNS server) then DAM users can take advantage of the protocol but without potentially compromising asset security.  It doesn’t seem that difficult for a method to be used to keep some kind of external link (e.g. an encrypted identifier etc) to allow them to be moved externally if there was ever a need to do that also.  Embedded metadata would probably help here too.

 

I think this is partly what Ray Gauss mentioned during the call, we’re needing to look at some kind of scalable ‘DNA’ where people can start off quite quickly and then a range of other capabilities they can scale up to.

 

I’m currently trying to think through this more basic document/asset model and how that might be structured.  We really need to bring some more developers who are directly involved in implementing DAM into this discussion (especially those current tasked with interoperability requirements).  We can ‘blue sky’ a lot of great ideas on this forum, but we need some people who are going to have to make it happen to reality check the suggested methods.

 

Thanks,

Ralph

 

 

From: dam-cmis-profile-discuss@lists.oasis-open.org [mailto:dam-cmis-profile-discuss@lists.oasis-open.org] On Behalf Of David Choy
Sent: 04 November 2013 18:22
To: ralph@daydream.co.uk
Cc: dam-cmis-profile-discuss@lists.oasis-open.org
Subject: Re: [dam-cmis-profile-discuss] RE: Key Objectives For CMIS/DAM

 

Hi Ralph,

If I understand the current practice correctly from our first conf call, the exchange/distribution/sharing of DAM info between two parties seemed to be by sending info directly between them using a common format and following certain rules. If there is no server involved in this exchange that can enforce the rules or constraints, then apparently a satisfactory exchange would rely on each party's self-discipline and correct/complete understanding of the rules and constraints. It would also rely on the trust one party has in the other party.

If this is indeed the case, I wonder if it makes sense to have a DAM server sitting in the middle of this exchange to enforce DAM rules/constraints/semantics, handle security, assure asset authentication, and manage rights. An asset owner can deposit assets into this server, and send links to a recipient for him to retrieve assets from the server. Alternatively, a consumer can just search the server directly to find/get what he wanted. This server may be maintained by a third party as a digital asset clearing house or marketplace, or maintained directly by an asset owner. In the latter case, the server also manages the assets for the owner.

If this scenario makes sense, then this DAM server is much like a CMIS server with additional object types and constraints defined for DAM application. This would be fairly easy to do, and an ordinary CMIS client may suffice to access DAM info. The DAM specification can define a set of DAM required metadata properties. Each asset owner can create sub-types to add custom properties for managing his assets.
If there are additional operations (besides the current set of CMIS services) the server needs to perform for DAM application, perhaps they can be packaged as a DAM Feature, which could be optional for CMIS compliance but required for DAM.

Does that make any sense?

David

 

On Mon, Nov 4, 2013 at 8:20 AM, Ralph Windsor <ralph@daydream.co.uk> wrote:

Hi David,

 

Thanks for the details on this also.  I’m going to try and assimilate this with Florian’s post and see I can think of some ways forward.

 

Thanks,

Ralph

 

From: David Choy [mailto:david.choy500@gmail.com]
Sent: 03 November 2013 02:46
To: Mueller, Florian
Cc: ralph@daydream.co.uk; dam-cmis-profile-discuss@lists.oasis-open.org


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

 

 

I wrote the following offline yesterday. It would complement Florian's post.



---

CMIS is a generic, interoperable, client-server interface which enables a client to manage content stored in a CMIS-compliant content management repository. A CMIS repository is logical. The CMIS interface may be mapped (typically by a system provider or a service provider) onto a physical content management system. Many popular content management systems have supported a CMIS interface on top of their native interface (e.g. Filenet, Documentum, Sharepoint, Open Text, Alfresco, and others). There are open source implementations of CMIS, such as the Apache Chemistry project which has implementation for both server and client.

The CMIS specification can be separated into two parts. The first part defines the abstraction for a CMIS repository. It includes a repository data model and a set of services that a client may use to access a CMIS repository. The second part describes the protocols a client actually uses to communicate with a CMIS repository. CMIS leverages popular protocols instead of inventing a new one. Since the popularity of communication protocols changes over time, the core of the CMIS specification is by design decoupled from any specific communication protocol. Currently, CMIS defines protocol bindings for SOAP-based Web Services (a service-oriented protocol), for AtomPub (a resource-oriented RESTful protocol), and for browsers (leveraging the capabilities that a modern web browser has). Each binding describes how CMIS information is passed/interpreted using the respective protocol. A CMIS client may use any of the three bindings to access a CMIS repository.

The CMIS data model is based on the concept of typed objects. An object may be a standalone information entity (such as a digital asset), a folder, a relationship between two objects, or a management policy. Each object has a system-assigned, unique (within the scope of the given repository), and persistent object id; has a fixed primary object type, and zero or more additive secondary object types; has a number of metadata properties; and optionally has content streams. Content streams are opaque to CMIS, and can be primary content, thumbnail, or other unstructured data. Much of the data model actually deals with metadata. A metadata property may be defined by CMIS, by a repository, or by an application or a user. A primary object type specifies a set of properties that each object of that type must have. In addition, an individual object, regardless of its primary object type, may have additional properties specified by the secondary type(s) that the object is associated with. During the life span of an object, secondary types may be added to or removed from the object. CMIS does not define NULL value for properties, but a property may be left unset. Some properties are maintained by system (such as an object's creation time). Others may be "required" (i.e. they cannot be left unset). An object type definition specifies all the attributes of an object type, plus a list of property definitions which in turn specifies all the attributes of each property. From object type definitions, an application can programmatically discover what kinds of objects there are in a repository. Furthermore, an application can create new object types to accommodate application-specific metadata.

CMIS supports type hierarchies with single inheritance. Each subtype of an object type inherits all the property definitions of its parent type, and may have additional property definitions of its own. Five root primary object types are specified by CMIS: Document, Folder, Relationship, Policy, and Item, each carrying a base set of properties for CMIS to function properly. An application may, for example, create a new object type called "Book" as a subtype of "Document", inheriting all its properties, plus additional properties: "Authors", "Publisher", etc. It may further create another object type "Tour Book" as a subtype of "Book", inheriting all its properties, plus additional properties such as "Geographic Region". However, creation of a new root primary object type is not allowed, but creation of new root secondary object types is allowed.

Besides standalone info objects (the "Document" type and its subtypes), CMIS supports a hierarchy of folder objects. An info object may be filed into one or more folders, or left unfiled. Furthermore, a binary relationship between two objects may be represented by a relationship object and described by the relationship object's properties. Multiple relationships may exist between two given objects. Policy objects are used to hold management policies which can be applied to other objects. Item objects may be used to represent entities that do not fit the mold of the other four kinds of objects.

CMIS services cover the basic CRUD operations (Create, Retrieve, Update, Delete), navigation (through the folder hierarchy and relationship objects), and SQL-based query with extensions to support fulltext search and scoping by folder. Other CMIS features include object retention and hold, ACL-based object-level access control, and document versioning.

David

 

 

On Fri, Nov 1, 2013 at 2:10 PM, Mueller, Florian <florian.mueller02@sap.com> wrote:

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

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]