Re: [cmis] Scope of Hierarchical Properties

["David Nuescheler" <david@day.com>]

Hi,

I agree with Julian's statements.

Since David C. expressed an interest in use cases I could volunteer two
very common use cases to the discussion that I happen to come across
frequently.

(1) 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.

(2) Persisting and Querying XMP [1]
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.

While I do not necessarily advocate the inclusion of hierarchical properties
in v1.0 of the specification I think the above are fairly straight
forward common
use cases that could be considered.

regards,
david

[1] http://en.wikipedia.org/wiki/Extensible_Metadata_Platform


On Tue, Dec 16, 2008 at 6:09 PM, Julian Reschke
<julian.reschke@greenbytes.de> wrote:
> Hi,
>
> this certainly looks like a feature set that will be hard to standardize.
>
> Maybe it makes sense to look at how others have dealt with it?
>
> 1) JCR doesn't have structured properties per se, but can support complex
> hierarchies of content nodes. So the structure is not *in* the properties,
> but in the tree of nodes they are contained in.
>
> This approach is very flexible, and also solves the issue of queryability.
> On the other hand, it's also hard to implement on top of systems that do not
> happen to support this in the first place.
>
> 2) WebDAV properties can complain arbitrary XML, thus any kind of hierarchy
> *can* be represented inside a WebDAV property (*). This is extremely simple
> to implement in a repository (essentially it can treat those properties as
> strings, with only one additional flag stating it's XML).
>
> The drawbacks here are that the property can only be manipulated and
> access-controlled in total, and that there's no solution for query (yet).
>
> ...both approaches are flexible and can represent just anything; but because
> of their flexibility clients and servers are more tightly coupled (because
> they need to understand the specific format/structure).
>
> BR, Julian
>
> (*) Of course binary values would be problematic...
>
>
> --
> <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
> Amtsgericht Münster: HRB5782
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>



-- 
Visit: http://dev.day.com/