[occi-wg] Yet Another (non)Link Proposal

[Gary Mazz]

Hi,

Whichever proposal we go with, I think you have a legitimate request for 
the look ahead feature.

cheers
gary

Csom Gyula wrote:
> Hi!
>
> Thanks for the reply, now it's quite clear:)
>
> * Within the core there is no (rich) support for "relationship-relative roles", that is the entity
>   role (1) is specified by its Resource type and (2) could be further specified through Category
>   field(s).
>
> * When using extensions things might be different, ie. it might be possible to expose relationship-
>   relative roles by introducing a 'rel' attribute or kinda into Associations. Let me put my 'vote' on
>   adding such support:)
>
> Cheers,
> Gyula
>
> ________________________________
> Feladó: gary mazzaferro [garymazzaferro at gmail.com<mailto:garymazzaferro at gmail.com>]
> Küldve: 2010. augusztus 18. 8:18
> Címzett: Csom Gyula
> Tárgy: Re: [occi-wg] Yet Another (non)Link Proposal
>
> Hi... inline again..
>
> 2010/8/17 Csom Gyula <csom at interface.hu<mailto:csom at interface.hu>>
> Hi!
>
> Thanks for your response!
>
> I've got the point: Rule2 below declares a multiplicity constraint (ie. one and only one... resource
> could be referenced). However regarding extension/association, it is not yet clear where and
> how you expose the roles. As stated below the role is specified by the extension, the question
> is how:)
>
> Lets take a theoraticel example (emphasis put on theoratical:)). I want to introduce n-tier
> semantics to OCCI through custom associations so that I define the following ones:
>
> * frontend references to a compute playing the frontend role (ie. UI)
> * application references to a compute playing the application server role
> * and finally db references to a compute acting as a database server
>
> For some reason application server (the entity) is linked to both the front end and db tier. Hence
> it (the entity) will have 2 associations referencing to the same resource type (Compute) but with
> different roles ('front end' and 'db'). So my extension has to differentiate between these
> associations somehow.
>
> In occi, the roles for occi entities are defined by the Category field. To differentiate  ('front end' and 'db') the entity's category information are read by the consumer. If the header contains only the one Category (application server), the other Categories (occi entities) are gathered through additional http GET requests.
>
> If the header contains multiple Category feilds are where it gets interesting.. If you are reading the http headers and the header supports multiple Categories (occi entities), the header must be transversed to locate it (the entity). This also means we need a way to reference the "in header"  (local copy)  of the Reference Resource.
>
>
>
> After all the question is: where and how can i declare these roles when I define the above 3
> custom associations? is there a 'role' an attribute of the Association? or is association a named
> element and its name declares its role? rel attribute should be used? any extension must include
> only one association (to a given entity)? or some other technique?
>
> I think you are looking for a way to preview aspects of the Reference and Association. Under current definition of the a Reference, there is only one implicitly defined relationship support, a "binding" between occi Resources. I do not believe there is any reason to explicitly define the relationship.
>
> For the Association, I can see potential for exposing the destination's relationship information. However, it adds cruft to interoperability, but so does ID, Title and Summary. I guess adding the 'rel' attribute can't hurt.
>
> Gyula
> ________________________________________
> Feladó: Gary Mazz [garymazzaferro at gmail.com<mailto:garymazzaferro at gmail.com>]
> Küldve: 2010. augusztus 17. 15:36
> Címzett: Csom Gyula
> Másolatot kap: Edmonds, AndrewX; occi-wg at ogf.org<mailto:occi-wg at ogf.org>
> Tárgy: Re: [occi-wg] Yet Another (non)Link Proposal
>
> Hi Csom,
>
> Thanks for the response answered inline
>
> Csom Gyula wrote:
>   
>> Hi,
>> I think using different terms for the different layers (entity model vs. http/html representation)
>> is a practical thing:) There's one point though I couldn't catch in the proposal. The following
>> rule is not intuitive for me:
>>
>> "Rule 2: One occi element is represented by one Reference."
>>
>> What does 'one' and 'represent' mean here?
>>
>>     
> In this definition, I meant only one (1) occi element can be represented
> in a Reference field. In other proposals you could place multiple occi
> elements in the link field. This is not the case here.
>
>   
>> * By the classical term a reference is made from one entity to another hence a reference
>>   doesn't represent entites rather relationships between them.
>>
>>     
> You make a good point and identify an hole in the proposal language. I
> was making the assumption that References and Associations exist as part
> of a Category, similar to the current link feild. That assumption should
> be clearly defined as a Rule. So, the occi element including the
> Reference is implicitly one end point of the the relationship and the
> occi entity contained in the Reference is the other end point of the
> relationship. This is also true of Associations. I'll clean that up today.
>   
>> * Also by the classical term different references could be given to the same entity. That
>>   is supported by roles which specifie the entity roles within the relationship. Currently
>>   the OCCI entity model is simple enough so that Resources specify their roles. However
>>   when thinking of extension this might not be true... the same entity could play different
>>   roles...
>>
>> I might missed something..., so could you please clarify the above rule?:)
>>
>>     
> Extension are directed at Associations. The role of the Association is
> defined by the extension and not the occi definition of the extension
> "end point"/"point of presence".  The fact that some URI is placed in
> the Association field, already defines the relationship to the occi
> element as an extension. I took that approach to limit the number of
> explicitly defined roles and relationships. By placing the the
> relationship with the extension, it allows extension greater flexibly in
> terms of definition.
>
> We find a similar scenario with examining the 'rel' attribute
> definitions in the IETF Link Header Proposal. There are some rel
> attribute definitions that are significant for occi, while others are
> irrelevant and some occi relationships are not described at all in the
> 'rel' registry. I wanted to avoid that scenario.
>
> I hope I cleared up your questions.
>   
>> Cheers,
>> Gyula
>>
>> ________________________________
>> Feladó: occi-wg-bounces at ogf.org<mailto:occi-wg-bounces at ogf.org><mailto:occi-wg-bounces at ogf.org<mailto:occi-wg-bounces at ogf.org>> [occi-wg-bounces at ogf.org<mailto:occi-wg-bounces at ogf.org><mailto:occi-wg-bounces at ogf.org<mailto:occi-wg-bounces at ogf.org>>] ; meghatalmazó: Gary Mazz [garymazzaferro at gmail.com<mailto:garymazzaferro at gmail.com><mailto:garymazzaferro at gmail.com<mailto:garymazzaferro at gmail.com>>]
>> Küldve: 2010. augusztus 17. 12:04
>> Címzett: Edmonds, AndrewX
>> Másolatot kap: occi-wg at ogf.org<mailto:occi-wg at ogf.org><mailto:occi-wg at ogf.org<mailto:occi-wg at ogf.org>>
>> Tárgy: [occi-wg] Yet Another (non)Link Proposal
>>
>> Good work, Andy's write up seems to capture many of our issues, from current linking discussions in [1].
>>
>> I think we need to revisit the reasons why we have linking in the first place.
>>
>> 1) Initially we knew we weren't able to capture all aspects of cloud architectures and our preliminary work would need to be extensible. We needed a way to integrate changes into occi.
>> 2) We also realized we would need to integrate vendor proprietary  implementations.
>> 3) Additionally, we decided that we need to breakup the occi represented resources into small parts for easy transport and support devices like mobile phones.
>>
>> This was all  decided prior to the introduction of the occi http header implementation.
>>
>> During this process, we decided to use linking, again prior to headers, to represent both References between resources and Associations between representations out of occi's scope.
>>
>> This approach intuitively combined issues surrounding data context and data data description into an predetermined implementation as a 'link'. I think link we need to further define the term as 'Link' which refers to OCCI both type of occi associations and the 'link' for the implementation used in headers and HTML/RDFa.
>>
>> The Proposal:
>>
>> Name Changes:
>> I would prefer to see 'Link' to be renamed to "Reference' and 'Association' where appropriate in the occi specification.  It would help limit confusion on the part of implementors and contributors.
>>
>> New Definitions:
>>
>> Reference: A portion of the occi logical model representing an occi configuration indicating a binding relationship between occi entities.
>>
>> Association: A portion of the occi logical model representing an occi configuration indicating a bind relationship between occi entities and systems outside the scope of occi.
>>
>> Logic Rules:
>> Reference:
>> Rule 1: All References are part of the occi name space.
>> Rule 2: One occi element is represented by one Reference.
>>
>> Association:
>> Rule 1: Associations are used to extend occi  with system entities outside of occi's scope. Interoperability cannot be guaranteed across occi extensions.
>> Rule 2: Although indented for external systems, occi entities may be a defined in Associations. This would help ensure backward compatibility if an extension is adopted and becomes part of the occi name space.
>> Rule 3:  Detailed information about the occi extension is only available after the extension is loaded be the extension consumer.
>> Rule 4: The URI is mandatory for an Association.
>> Rule 5: An occi Title attribute is mandatory for an Association.
>> Rule 6: An occi Summary attribute is optional for an Association.
>>
>>
>> Header Implementation Details:
>> Remove the Link field from the header definition and replace it with the appropriate Reference  and  Association header field.
>>
>> Header Implementation Benefit:
>> 1) Reduces Link attribute parsing complexity
>> 2) Reduces provides better clarity of the information's purpose
>>
>> HTML5/RDFa Implementation Details:
>> TBD
>>
>> I'll follow up with examples if there is interest
>>
>> cheers,
>> gary
>>
>>
>>
>>
>> [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
>>
>>
>>
>>     
>
>
>
>