[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cmis] Considering use cases for relationships in CMIS
Hi David, thanks for your swift and thoughtful response. > We must be one of the two vendors you mention :-). I realize that my research was not exhaustive enough ;) ...up to 3 vendors ;) (which I would agree, makes a difference.) ...and maybe there are more to come. > My experience has been that typed relationships are a generally useful > data modeling tool. That's good to hear. > - They can bear typed metadata which is independent of either related item. > The current thumbnail/preview discussion illustrates this. ...while I appreciate this as a characteristic I have to say that I fail to see the benefit of that in practice. Maybe a use case would be helpful for me to understand, I think I may have missed that in the thumbnail/preview discussion. > - 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. I agree. Personally, I think that a relationship in the simplest case should be pointing from the subject to the object. Proably something like a "relationship" property that points from one CMIS object to another CMIS object. Of course it is simple to then start modeling arbitrary relationship objects based on two (or more) "relationship" properties and meta data with typing and all the additional goodies. > - 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. While I agree that there may be use cases where separate lifespan, access control are beneficial I would argue that in many cases this may further complicate the most simple use case. > 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"? Opaque semantics I think are one thing. But on top of that you would have a layer of opaque object type ids to work with that will vary from repository to repository even if I would want to express the same "application internal" semantics. > 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 believe that if an application can identify a relationship by "name" (a fixed vendor neutral string) rather than by a changing object type id, things would make a lot more sense to me. Maybe this is already possible and I overlooked something. > 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. I agree that the relationship model should be capable of handling simple usecases like thumbnails. I must be missing something but I think that a simpler model could also encapsulate that. regards, david > 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 >> > > > --------------------------------------------------------------------- > 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 > -- David Nuescheler Chief Technology Officer mailto: david.nuescheler@day.com web: http://www.day.com/ http://dev.day.com twitter: @daysoftware
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]