[occi-wg] Categories and Collections
alexander.papaspyrou at tu-dortmund.de
alexander.papaspyrou at tu-dortmund.de
Wed Oct 6 02:36:16 CDT 2010
I'd probably keep the "core" namespace for categories. This ensures that (a) we don't have unnecessary namespace clutter and (b) that we can declare this very namespace as reserved for occi core normative extensions.
Am 04.10.2010 um 22:56 schrieb Edmonds, AndrewX:
> Hey Ralf,
> I've placed my replies inline...
> -----Original Message-----
> From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of
> Ralf Nyren
> Sent: Monday, October 04, 2010 5:42 PM
> To: Andy Edmonds; occi-wg
> Subject: Re: [occi-wg] Categories and Collections
> Nice work Andy!
> A few comments:
> - Could we have some HTTP-rendering examples of how to add/remove Kind
> instances to/from a collection other than the defining collection?
> AE: I'll get some examples added asap.
> - The section on Navigation refer to Links and Actions, is this the Core
> base types referred to? The Core Link type has little to do with paging
> from my point of view. The Link Header in HTTP on the other hand can be
> used for _both_ representing Core Links and paging. I see how Core Actions
> can be used to express paging but the way Actions are rendered in HTTP
> using Link Headers has again little to do with the Link base type. Please
> see "Actions and the Link Header" at the end of  for a full description
> of this terminology confusion.
> AE: Ooops my mistake - Actions should not have been mentioned (I'll make
> that edit). Paging through collections should be accomplished using Links
> (e.g. in HTTP header renderings) as you point out. A beginning example can
> be found here  in section 126.96.36.199. We need to make sure that the current
> incarnation of Links can accommodate this behavior.
>  http://www.ogf.org/Public_Comment_Docs/Documents/2010-01/occi-core.pdf
> - When the http://schemas.ogf.org/occi/core# was introduced I thought it a
> good idea to have it reserved for Categories defining the OCCI base types
> (i.e. Resource, Link, Action). Although not necessary I think keeping this
> distinction make the spec a bit easier to understand. The current
> definition of Categories is:
> The Category type represent the classification mechanism used by OCCI. It
> MUST be implemented. From a system point of view a Category is used for
> two different classification purposes. See also section 4.3 "Type System".
> 1. Taxonomy. A Category is used to assign static type information to each
> resource type inheriting Kind or a descendant of Kind. This use of
> Categories denotes the OCCI "static type system". A unique Category MUST
> be assigned to every descendant of Kind. See the section 188.8.131.52
> 2. Folksonomy. A Category can be used to assign tags to resource instances
> via a mix-in like model. A Category mix-in MUST NOT be related to an OCCI
> base type (or any descendent of Kind) and MUST NOT be the unique
> identifier thereof. Example use cases are collections, location
> information and templates for virtual machine provisioning.
> Collections play nicely with 2, the "folksonomy" use of Categories. My
> point is that maybe we should have different schemes for Category use case
> 1 and 2, that is for Categories defined in Core. What do you think? It is
> not terribly important though.
> I.e. use a different scheme for the "tag" Category.
> AE: we could use something like
> "http://schemas.ogf.org/occi/core/collections#" as the scheme for tags?
> I will annotate the wiki page as well.
> regards, Ralf
>  http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Link
> On Sun, 03 Oct 2010 17:16:57 +0200, Andy Edmonds <andy at edmonds.be> wrote:
>> Hey all,
>> I've placed a write up of how categories and collections related to each
>> other. Also there is how one can interact with collections. I've tried to
>> keep the description as non-rendering-specific as possible.
>> If there are comments etc please annotate the wiki page at the
>> place or place your questions in the "Open Issues" section.
> occi-wg mailing list
> occi-wg at ogf.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4678 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20101006/3e3fbba0/attachment.bin
More information about the occi-wg