Re: [cmis] Considering use cases for relationships in CMIS

[David Pitfield <david.pitfield@oracle.com>]

Hi David -

We must be one of the two vendors you mention :-).  My experience has 
been that typed relationships are a generally useful data modeling tool.

- They can bear typed metadata which is independent of either related 
item.  The current thumbnail/preview discussion illustrates this.

- They can be queried with "is a" semantics (that is, a specified 
relationship type and its subtypes).  Since relationships can bear 
metadata, this is particularly useful, since additional metadata is 
often added by subtyping.

- As independent objects, they can be created, updated, and deleted by 
users who don't have privileges to update either of the related 
objects.  They have have their own lifespan, policies, and audit history.

You raise the issue of relationship types being opaque to the 
application.  Wouldn't we have the same issue if we replaced 
"relationship types" with "relationship names"?  In either case, 
wouldn't there need to be a registry of types/names, in order to agree 
on semantics?  (Some core types/names might be specified by CMIS, as 
we're contemplating for thumbnail/preview.)

I prefer that CMIS have a general-purpose approach to relating items 
(such as the current relationship model), and use this as the basis of 
features such as thumbnails and renditions, rather than have a simpler 
relationship model and introducing new data models of services for each 
such feature.

Regards.
dbp

David Nuescheler wrote:
> 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
> relationship,
> 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
> "is-derived-from"
> relationship.
>
> ---
>
> 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.
>
> regards,
> david
>
> ---------------------------------------------------------------------
> 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 
>
>