HierarchicalProperties_Proposal - Content Management Interoperability Services (CMIS) TC Wiki
Content Management Interoperability Services (CMIS) TC Wiki
HierarchicalProperties_Proposal
FrontPage
RecentChanges
FindPage
HelpContents
Hierarchica...es_Proposal
Immutable Page
Comments
Info
Hierarchical Properties
Possible Features
Dependent Pick Lists
Structured Documents
Relationship within properties
Multilingual properties
More detail here
Other references here:
Scope of Hierarchical Properties
Comments
worthwhile to understand to how expose Pick List Dependencies, Language, Rendition, and Multi-Lingual.
Relationship within properties only in some (few?) repositories
others by patterns and best practices
nice to have for 1.0 not a requirement up to now
looking for use cases do determine importance of this
should focus only on most important functionality for 1.0
Suggestions
A possible model could be:
property = single-valued-property | multi-valued-property | list-
property | map-property
single-valued-property = (the one in CMIS 0.5)
multi-valued-property = (the one in CMIS 0.5)
list-property = list of map-property with identical schemas
map-property = map of key -> property obeying to a fixed schema
This roughly the model that Nuxeo uses. It allows for the
representation of structures like (JSON):
{ "title": "Report on use of automobiles",
"subject": ["cars", "transportation"],
"authors": [{"firstname": "Bob", "lastname": "Smith"},
{"firstname": "Pete", "lastname": "Wu"}]
Relations to other standards
JCR
does not natively support hierarchies in properties but instead a hierarchy of nodes, structure is in the hierarchy of nodes
(+) flexible
(+) solves query
(-) hard to implement for repositories not supporting such a concept
WebDAV
properties can be XML
(+) extremely easy to implement (in simpels case jus a string)
(-) only accessible and access-controlled in total
(-) no good solutions for query
open topics / things that need to be discussed
how to integrate in this query
preserve design principle: CMIS to be implementable on top of existing repositories
structured documents very complex topic for itself
define relationship with XML / xquery
do we need namespaces
Use Cases
Thumbnails
After loading a document into a CMIS enabled repository it would be great to have an CMIS application add a number of thumbnails in various sizes into a "thumbnail" structure. Since the thumbnails themselves semanticly should not be treated as an individual document, since this would clutter the namespace the thumbnails should be treated as structured meta-data.
Persisting and Querying XMP
Since many modern file formats (PDF, JPEG, ...) support XMP data upon ingestion the XMP information could (probably should) be extracted by a repository (or any thirdparty CMIS app).
This should be done in a fashion that allows for query of the respective information, since of course XMP holds a wide variety of potentially very useful information.
more general: how to map RDF from/to CMIS/JCR/WebDAV
[DavidC] If extracting XMP data is all that is needed, would it be easier to invoke a utility outside CMIS for that purpose? Otherwise, what file formats a CMIS-provider is be required to interpret and extract metadata? On the other hand, if XMP metadata remain embedded in a file (as a part of the CMIS abstract data model), how should query work?
Discussion
Some comments that came up during conf call on Dec-17th-2008 (only few participants):
Relation to name spaces
Some tendency to postpone the whole topic for a later spec release than 1.0
If postponed must ensure backwards compatibility
Some tendency in prioritization of multilingual, version specific properties, dependent pick lists, array and map types, but not of structured/complex documents and relations
HierarchicalProperties_Proposal (last edited 2009-08-12 18:02:33 by
anonymous
Immutable Page
Comments
Info
MoinMoin Powered
Python Powered
GPL licensed
Valid HTML 4.01