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


Help: OASIS Mailing Lists Help | MarkMail Help

cmis4dam message

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

Subject: Minutes of Meeting on June 16, 2015

The CMIS4DAM TC Meeting 16 June 2015


Ken Baclawski, Northeastern University
Peter Beemster, SDL
Ray Gauss II, Alfresco Software
Florent Guillaume, Nuxeo
Irina Guseva
Carsten Hoffmann, Canto, Inc.
Sascha Homeier, apollon GmbH+Co.KG
Gershon Janssen

1. Voting Membership

There were 6 voting members out of 6 at the meeting so there was a
quorum.  There were no changes in voting rights.

2. Query Languages

The consensus was that the metadata must have these characteristics:

a. It must support structured data.
b. The metadata must be queryable.
c. Relational data is not adequate.
d. Namespaces must be supported.

Much of the discussion was concerned with the query language. Here are some choices:

a. XPath is succinct and powerful but may not be sufficient.
b. XQuery includes XPath and has powerful features.
c. A JSON query language. There are several of these but they are not
   very standardized and namespaces are not well supported.
d. SPARQL is mainly for RDF graphs.
e. OData is similar to XPath and is a well developed standard
   but is designed for RESTful interaction which clashes with CMIS.

JSONiq is a query and functional programming language that is designed
to declaratively query and transform collections of hierarchical and
heterogeneous data in format of JSON, XML, as well as unstructured,
textual data.  (See https://en.wikipedia.org/wiki/JSONiq) However,
JSONiq does not currently support updates.  It has a data model that
extends the XQuery and XPath Data Model.

One suggestion was for simple properties be handled using CMIS, but
more complex values would be expressed using XML or JSON.  But this
complicates queries.  This could be mitigated by mapping both simple
and complex properties to a single data model which could then be

One could specify property "names" using XPath expressions which would
allow one to get and set properties in a complex structure almost as
if they were simple properties.

It would be helpful to give some examples on the wiki.

3. Use Cases

Irina Guseva moved and Ken Baclawski seconded that the Use Cases
published on the wiki be accepted as the first deliverable.  The
motion passed unanimously.

The following are the use cases:

CMIS4DAM Use Cases


    System. An entity that complies with the DAM standard. This is
    more general than the CMIS notion of a repository. A DAM-compliant
    system need not be a repository. It could, for example, be a web
    server that supplies content from CMIS repositories or other
    DAM-compliant systems. It might be better to call this actor a

    Application. An entity that manages or uses assets. Unlike a
    system, an application need not be DAM-compliant.

    Federation. A system that federates multiple autonomous
    DAM-compliant systems that may be unaware that they are being


The use cases are arranged in categories of use case for convenience
and to relate them with the CMIS4DAM-specific use cases.

    Metadata access and integration. There is no corresponding CMIS
    use case. CMIS4DAM addresses metadata interoperability and

        Metadata interoperability. While virtually all digital asset
        managers support XMP, there are many other metadata
        standards. Expression, representation, serialization of that

        Metadata disambiguation. Different vocabs expressing the same
        data points: IPTC as Dublin Core, or any domain-specific
        fields that are not part of any metadata standard.

    System-to-System. In this use case, systems interact with each
        other. The CMIS use case is Repository-to-Repository
        (R2R). The CMIS use case includes A and B (for documents) but
        not C or D.  One system manages assets that are stored in
        other systems.  Publishing assets from one system to another

    Application-to-System. This is an asymmetric interaction. The CMIS
    use case is Application-to-Repository (A2R). The CMIS use case
    includes A and B for documents.

        Collaboration systems. The ICOM TC has developed a detailed
        object model for interoperation between collaborative
        systems. The ICOM object model is, in principle, expressible
        as a CMIS profile although this has not yet been specified.

        Desktop systems. Various applications could use a
        CMIS-compliant repository for managing their documents. This
        would also be possible for DAM-compliant systems.

        Asynchronous access. Assets may be accessed asynchronously. In
        particular, an asset might not exist yet, could be ordered,
        and the requesting application would be notified (via server
        push) when the asset is available. The first version of
        CMIS4DAM will only specify pull coding (polling).

        Rendition technical information. The technical properties of a
        rendition will be specified by metadata. This requires the
        metadata use case.

    Federated Systems. A system that federates multiple autonomous
    DAM-compliant systems that may be unaware that they are being
    federated. Federation enables you to find assets, but doesn't
    allow editing.

        Federated Search. A single query of a single node may be used
        to search multiple repositories. CMIS4DAM does not specify how
        different metadata standards would be mapped to enable
        federated queries.

        Federation instead of migration. A legacy repository would be
        federated with a new repository. Old content remains on the
        legacy repository until it becomes outdated or is
        migrated. All new content is on the new repository.

        System Integration. For example, between WCM and DAM, between
        PIM and DAM, between media management and media delivery.

5. Action Items

The members should start looking for examples.  The wiki can be used
for this purpose.

Irina Guseva will set up a link to a Google document with the

6. Next Meeting

Tuesday, July 21, 2015.

Respectfully submitted,

Ken Baclawski

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