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: Considering use cases for relationships in CMIS

Dear TC Members,

after some more detailed analysis in of the relationship model exposed in CMIS
and some more research on relationships in general (eg. rdf) I found myself
questioning the current approach that we are taking in CMIS on relationships.

Personally, I was always somewhat surprised by the idea that someone wanted
to have an inheritance based object typing model on the predicate of a
but I think this becomes a true inhibitor for applications given that
we don't have a
means in CMIS to register an object type.

I played through a couple of use-cases that came to mind, please let me know
if I completely miss the point of relationships here:


Usecase 1: Application specific relationship

Let's say I am pdf generation application application and I would like
to express
the relationship between a "pdf output"-document and it's original
"ms word source"-document with a relationship "is-derived-from".
Since I cannot register object types I think I would have to rely on the
content repository administrator to go in and create the relationship for me.
Since I do probably not have an idea on what the object types are in a current
install there is very little instruction that I could give the
repository administrator
on how to do that, and of course it would be very vendor specific.
I would assume that I would get back an object type id (something non-readible
to a human) that I would have to register with application as my


Usecase 2: Use existing relationship
My application wants to leverage existing relationships and want to find an
relationship that has been predefined either by the system or by someone
using the above manual registration process.
It seems to me that the only reasonable means that I would have to
find a pre-defined
"is-derived-from" relationship is the "display name".
The inheritance graphs and the object-type-ids are different from
vendor to vendor and possibly from install to install.


As I said before I may have missed the point of the use cases and of course
I would be very interested to learn what general use cases we had in mind when
specing the relationships.

Given the usecases above and also given that most repository implementations
that I am aware of (including sharepoint afaiu), it seems like both the clients
and the implementations would be better served by something that identifies
the predicate by "name" and does not require heavy-weight registration of
object types.

In my somewhat broader research I have not found (m)any practical usages of
predicates in relationships that require a complex typing systems, but it seems
like the world (rdf, sql, atom, html, etc.) has standardized on the model where
a relation is identified by a name (rdf -> element or attribute, sql
-> column name, ... )
and is usually contained in the subject of the relationship.

Long story short, while I appreciate that a few repository vendors (I
found two ;) )
for historical reasons have modeled relationships this way, I think
there is almost no
value and a significant cost from an interoperability perspective
especially as long
as we don't have a means to either register or discover/know the semantic
meaning of a relationship for an application.

So my suggestion would be to drop the relationships as they are speced right now
for a more simplified and versatile "relationship" property type that
is then identified
by name. I think this would both help in schedule and size of the spec
in v1.0, without
harming any of the use cases and would not prevent us from bringing
the heavy-weight
relationships back in the future.


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