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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

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


Subject: RE: [cmis] CMIS stored query?


Our system exposes virtual folders in a hierarchy that is completely
independent of the physical folder hierarchy, so +1 to another system that
has the same pattern.  In addition, our system restricts the ability to
provision virtual folders in the normal folder hierarchy - they are
basically views across the folder hierarchy (where some views require query
semantics that cannot be expressed in CMIS SQL e.g. a permission filter).
A limited use case of allowing a repository to return a set of virtual
containers (either a subtype or folder or a new type) and browse the
container's contents (maybe reusing existing navigation services
operations?) and fetch a container (maybe using exiting object services
operation) is sufficient.  There are issues with path semantics that are
tricky, so agreed that more discussion is needed, but I think the end goals
being discussed here are all promising and worthy of a broader TC
discussion in a meeting.

Thanks,
---------------------------------------
Derek Carr
IBM Collaboration Solutions
(919) 254-8592 (t/l 444)
---------------------------------------



From:	Jens Hübel <jhuebel@opentext.com>
To:	Florian Müller <florian.mueller@alfresco.com>,
            <cmis@lists.oasis-open.org>
Date:	03/31/2011 11:50 AM
Subject:	RE: [cmis] CMIS stored query?



Well I don't think the current proposal is already in a state of a proposed
extension to the domain model. If relationships are the best way to express
this I think no one has excluded this option yet. So I don't get your point
here. Relationships don't have any semantics applied. So how should a
client know that a specific relationship is related to query or virtual
folders with the spec as it is today? We need some form of an extension.

We need to better understand what virtual folders mean. At least one of our
systems exposes them in a hierarchy that is completely independent of the
physical folder hierarchy. My question therefore is whether this is a
common pattern and whether we need this.

If I understand your last topic correctly your proposal is to use the
existing query mechanism to do the *execution* of the queries. The client
takes the template parameters and generates a query according to the
current syntax. Correct? Well this would be one possible solution.
Personally I don't see that this would be the best approach to do this but
definitely one option.

I think we are in a state where we need to find a common understanding what
we want to achieve with this. What are our use cases? What are the typical
operations? Then we can discuss how to map this to the current spec and
where we need extensions.

Jens


-----Original Message-----
From: Florian Müller [mailto:florian.mueller@alfresco.com]
Sent: Donnerstag, 31. März 2011 12:25
To: cmis@lists.oasis-open.org
Subject: Re: [cmis] CMIS stored query?

Let me ask some deliberately ignorant questions.

- A saved query basically represents a flat collection of objects. If I get
the object parents or the object children (if it is a folder) of an item in
this collection, I'm back in the real folder tree. So, how can a saved
query represent a virtual folder hierarchy?

- We already have means to express trees and graphs in CMIS that are
independent of the folder hierarchy: relationships. All you need is a
virtual root object and then follow the relationships. Create, copy, add,
remove, ... it's all there. So, why should we invent something new here?

- I'm struggling to see the difference between a template query and a
client generated query. If a client knows the semantics of a template and
knows how to fill the template parameters, it already has enough
information to build the query itself. A template query only makes sense if
we would define the semantics for a set of queries and query parameters in
the spec and repositories can provide different queries for it. So, is the
actual proposal to define taxonomies?


We should really explore first what is already in CMIS and maybe improve it
before we add more complexity to the spec. My 2 cents.


Florian


On 31/03/2011 08:04, Jens Hübel wrote:
> The interesting question then would be what the result of this call would
be. I think this is a good starting point but not the complete picture. We
need to decide on each of the following scenarios whether we want to
include them and how to specific them if yes:
>
> - get all templated queries (potentially a subset? paged? as query?)
> - get a templated query by id
> - create a templated/persisted/parameterized query
> - execute a query (and how to fill parameters)
> - create a virtual folder
> - get the contents of a virtual folder
> - add an object to a virtual folder
> - allowed operations on virtual folders (are they nested or flat?, copy?,
move?, delete?, ...)
>
> Need to specify what the difference between a  templated query and a
virtual folder is (if there is any):
> - templated query: I assume that a client can fill parameters, not sure
if this is true for virtual folder
> - virtual folder: may allow to add objects, might not be true for a
templated query?
>
> Could a query template be modeled as another object type where the
properties are the parameters?
>
> Well lots of questions and surely this is still not complete. It's not a
trivial thing.
>
> Jens
>
>
> -----Original Message-----
> From: Derek W Carr [mailto:dwcarr@us.ibm.com]
> Sent: Mittwoch, 30. März 2011 20:22
> To: Scott Malabarba
> Cc: cmis@lists.oasis-open.org
> Subject: Re: [cmis] CMIS stored query?
>
> I agree.  My understanding is that the footnote currently in the
> specification on GET for query collection was in place in order to not
> break AtomPub, but the general desire to get this concept in the domain
> model more formally is a very good thing in my view as it allows greater
> flexibility in allowing repository scope views for the scenarios outlined
> below.
>
> A potential domain model extension could be like the following:
>
> 		 DiscoveryServices.getPersistedQueries(String repositoryId, int
> skipCount, int maxItems)
>
> which would return a pair of total number of items available and a list
of
> virtual CMIS Folder objects that can be navigated, but cannot support
user
> defined filing semantics.
>
> The natural AtomPub mapping would be to do a GET on the query collection,
> but a corresponding mapping would be needed for SOAP/JSON.
>
> Thanks,
>   ---------------------------------------
> Derek Carr
> IBM Collaboration Solutions
> (919) 254-8592 (t/l 444)
> ---------------------------------------
>
>
>
> From:		 Scott Malabarba/Costa Mesa/IBM@IBMUS
> To:		 cmis@lists.oasis-open.org
> Date:		 03/30/2011 02:03 PM
> Subject:		 Re: [cmis] CMIS stored query?
>
>
>
> I think it's well understood that any new feature will be added to all
> bindings.
> We use AtomPub examples below just for informal exposition.
>
> I don't quite follow your concern about semantics.  Any semantics would
> be captured in the names of a saved query and its parameters -- same
> as with folders and object properties.
>
> Saved queries should be incorporated into the domain model in a way
that's
> generic and matches the way other objects are modelled.  The server
should
> not return a bunch of repository-specific data that standard clients will
> not
> recognize.  Does that help?
>
> Good point about scenarios.  Here, again, are two I'm thinking of:
> - Virtual folders.  Containers that look and act like folders but are
> backed
>    by a query or some other constraint, rather than filing.
> - Taxonomy-driven systems.  Some CMS systems rely mostly on metadata
>    and use folders lightly, if at all.  The spec has strong support for
> creating
>    and updating objects in this scenario but leaves the work of
retrieving
> them
>    to the client application (which must formulate queries).  Done right,
> saved
>    queries would enhance interoperability because a server could present
a
>    common taxonomy to multiple standard clients.  Without it, only
clients
> with
>    custom queries built in could retrieve content in a meaningful way.
>
> Regards,
> Scott
>
>
>
> From:        Florian Müller<florian.mueller@alfresco.com>
> To:        cmis@lists.oasis-open.org
> Date:        03/30/2011 10:14 AM
> Subject:        Re: [cmis] CMIS stored query?
>
>
>
> Saved queries/search templates/parameterized queries are rather useless
> in an interoperability scenario if the semantics are undefined. If a
> client doesn't know what the result set means, it will not execute the
> query.
>
> Rather than talking about how repository features can be pushed through
> CMIS, we should talk about the scenarios that we want to cover. If this
> results in domain model extensions, I am all for it.
>
> We should also avoid designing features from a binding perspective.
> Everything we add to the domain model should (must) work later with all
> bindings and we have three of them in CMIS 1.1.
>
>
> Regards,
>
> Florian
>
>
> On 30/03/2011 01:55, Derek W Carr wrote:
>> I am interested in expanding this support.  In our implementation of
CMIS
>> in Lotus Connections, we use this feature to advertise system queries
> like
>> files shared with me, files shared by me, trash, etc.  which were
>> equivalent to virtual folders in our system.  We chose to make the
> results
>> of the GET operation be a list of virtual folders that clients could
>> navigate like any other folder using the 'down' link relation to get the
>> results.  We do not yet have a need to persist new queries, but we would
>> like to see the domain model introduce better support for getting system
>> managed queries.
>>
>> Thanks,
>> ---------------------------------------
>> Derek Carr
>> IBM Collaboration Solutions
>> (919) 254-8592 (t/l 444)
>> ---------------------------------------
>>
>>
>>
>> From:                 "Churchland, David"<david.churchland@hp.com>
>> To:                 Scott Malabarba/Costa Mesa/IBM@IBMUS
>> Cc:
> "cmis@lists.oasis-open.org"<cmis@lists.oasis-open.org>
>> Date:                 03/29/2011 05:56 PM
>> Subject:                 RE: [cmis] CMIS stored query?
>>
>>
>>
>> I am certainly interested in the virtual folder model, also search
>> templates / parameterized queries.
>>
>> From: Scott Malabarba [mailto:scott.malabarba@us.ibm.com]
>> Sent: Wednesday, 30 March 2011 8:44 AM
>> To: Churchland, David
>> Cc: cmis@lists.oasis-open.org
>> Subject: Re: [cmis] CMIS stored query?
>>
>> I'm interested.  It'd be a useful feature and would provide better
> support
>> for taxonomy-driven systems.
>> I think supporting search templates / parameterized queries would be
> pretty
>> important.
>>
>> Any interest in allowing POST to a stored query?  Say, for example, if
> the
>> atom entry returned for a given stored query has the
>> <cmis:allowsPost>true</cmis:allowsPost>
>> property, then the client can post an object to the query's entry URL.
> The
>> server will create an object with metadata that matches the query.
>> The use case I have in mind is virtual folders:  I want the virtual
> folder
>> backed by my stored query to act like a real folder and let me
>> drag-and-drop content into it.
>>
>>
>>
>>
>>
>> From:        "Churchland, David"<david.churchland@hp.com>
>> To:        "cmis@lists.oasis-open.org"<cmis@lists.oasis-open.org>
>> Date:        03/29/2011 02:14 PM
>> Subject:        [cmis] CMIS stored query?
>>
>>
>>
>>
>> Here is a paragraph in the REST binding documentation that hints at a
>> nascent stored query capability in CMIS:
>>
>> This is a collection for processing queries. If the implementation
> supports
>> GET on this collection, then the implementation SHOULD at least return a
>> feed consisting of zero or more atom entries. These atom entries should
>> represent persisted objects related to query such as persisted queries,
>> long running queries or search templates.
>>
>> Does anyone else have an interest in incorporating this (as an optional
>> capability) into the domain model, e.g.:
>> ·         getQuery,
>> ·         createQuery,
>> ·         deleteQuery
>> ·         updateQuery
>> ·         query object supported in query
>>
>> My interest in this is mostly about having shared navigational
shortcuts,
>> for example a stored query of my favorite documents which I can access
> both
>> from my Desktop client and my mobile device client.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>
> ---------------------------------------------------------------------
> 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
>


---------------------------------------------------------------------
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


---------------------------------------------------------------------
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





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