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


David Nuescheler wrote:
> ...
> 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.
> ...

I think finding a pre-defined relationship could work if everybody 
supports the globallyUniqueName feature.

 > ...
> 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.
> ...

 From my limited understanding of RDF, you *can* "type" predicates using 
ontologies, but that feature is orthogonal to naming and totally optional.

> 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.
> ...

 From earlier discussions with Al I recall that a feature of the 
relationship model used in CMIS is that relations can outlive their 
source and target's lifetime, and that they can carry their own properties.

That of course could be modeled using a generic object as well. So my 
question is: why do relationships need to be a separate class? What 
makes them so special?

BR, Julian

-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782



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