cmis message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [cmis] CMIS stored query?
- From: Scott Malabarba <scott.malabarba@us.ibm.com>
- To: cmis@lists.oasis-open.org
- Date: Thu, 31 Mar 2011 12:23:44 -0700
One could argue that virtual folders could
be implemented entirely in the server
layer, by modelling them as folders.
In other words, the server could advertise
an entire hierarchy of CMIS folders
that are not physical folders but, rather,
backed by a query, external API call,
etc. These would be perfectly interoperable
with any CMIS client because, to the
client, they're just folders.
So, while virtual folders are an interesting
scenario, maybe it isn't necessary to
add them to the domain model. And
a static saved query is, arguably, the same
thing as a virtual folder.
Query/search templates are a different
story. A query template is an object that
has, as a property, a list of parameters
that it accepts. A client must specify values
for those parameters when it executes
the template. The template then returns a
set of objects.
There's no way for a client to specify
a set of parameters to a folder without using
an extension. So a server can't
model query templates with folders if they're going to
be consumable by vanilla clients.
The difference between a query template
and a client-generated query is that, well,
the latter is generated by the client.
The client application must have awareness
of the repository data model semantics
built into it.
The client, or at least the queries
it generates, will be specific to that repository instance.
Alternatively, the client could read
the repository metadata and present the user
with an interface for building queries.
In that case, the client is generic but the end user
must understand the data model semantics
well enough to build useful queries
(an unlikely proposition...).
With query templates, the data model
semantics need only be understood by the
server administrator (not the developers).
The end user has to understand what the
parameters he's being prompted to enter
mean, but that's all. Client applications
can be completely generic if
query templates are captured, in some way, in the domain
model.
It'd probably be possible to support
query templates as a well-defined set of metadata
and extensions. Then, client apps
would have to be built to support the extensions but
would not need semantic awareness of
the repository data model. We should explore
this further if stored queries don't
make it into the domain model -- they're a useful feature
and it's probably inevitable that someone's
going to implement them eventually anyway.
A lot of the obvious, general use cases
-- documents updated within X time window,
documents updated by user X, etc. --
don't really require query templates.
It's pretty easy to come up with use
cases within more specific problem domains. Case
management, for example. But I
haven't come up with anything truly compelling yet.
Very interested in other opinions here.
Regards,
Scott
Scott Malabarba
Software Engineer
IBM Enterprise Content Management
3565 Harbor Blvd., Costa Mesa, CA 92626-1420
Phone (714) 327-5133 / Tieline 3955133
Email scott.malabarba@us.ibm.com
From:
Derek W Carr/Watson/IBM@IBMUS
To:
Jens Hübel <jhuebel@opentext.com>
Cc:
cmis@lists.oasis-open.org,
Florian Müller <florian.mueller@alfresco.com>
Date:
03/31/2011 09:51 AM
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
---------------------------------------------------------------------
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]