[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]