[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 Attendees: 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
queried.
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
ACTORS
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
Server.
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
federated.
USE CASES
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
disambiguation.
Metadata interoperability. While virtually all digital asset
managers support XMP, there are many other metadata
standards. Expression, representation, serialization of that
metadata.
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
system.
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
deliverables.
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]