Array of references to related resources

Hi,

I have looked into this issue a bit more myself now so I thought I could post my findings so far. But I would still also like to have some comments or proposals from other forum members.

From looking into other Redfish and Swordfish schemas I have come the following conclusion:
- Relations (other than child/containment) to other resources are not only included as references under Link property of the resource, they may also be included via child collection resources on top/root level of the resource. (The collection will in this case contain references to resources that are not child resources, but instead are contained/child in other collections.)

Examples of this can be found e.g. in:
- ComputerSystem/HostedServices/StorageServices.
(assuming these are contained in “redfish/v1/StorageServices )
- Drive/Volumes
(assuming these are contained in “redfish/v1/StorageServices/<id>/Volumes)
- Swordfish: StorageService/Drives etc
(assuming these are contained in ComputerSystem/Storage/Drives)

This seems to be a possible “work-around” for my original issue, i.e. how to handled arrays in Link property (with related resources) that get to large. OK? Solutions is then to move them to be a non-Link property on root-level, and instead be a reference to a (child) collection that contains references to non-child resources. The collection will provide benefits such as support to $top and $skip. Would you agree to this conclusion?

Disadvantage with this pattern could be that original advantage with dividing resources properties into Link properties and other properties is partly lost. Because it is not possible to tell from a schema if collections outside Link property will contain reference to true child resources or if they will contain only references to items that has other parents. (I don’t think there are different types of collections for this pupose?)

Generally I think it would be a good idea to clarify the relations between resources in the specification somewhere. Specifically all parent-child (containment) relations should be good to clarify, e.g. via classical UML class diagram or via verbal description. Currently I think maybe the easiest way to find this out is to look at the mockups and make guesses based on the used URIs. (Because in most cases the URIs are built up to expose hierarchical child/containment relations.) But as URIs should be transparent, and no formal conclusion can be made from them, this is only a way to guess the intended hierarchy in an easy way. Formal specification would still be needed. Would you agree?
I still assume that we want (and need) the information model / schemas to define the actual type of relations between resources? And specifically clarify child/parent relations.

Description of these design choices and when to use which type of pattern (“Links-property” vs “Collection outside Links property”) for modelling of this type of relation (“non-child”) would also be good I think. (Currently I think only the “Links-property” way is described?) I think maybe also it would be a good idea to clarify that collections may include reference to contained/child resources, but also references to non-contained resources (that are actually child of other collection).

Hi Jeff,

Thanks for the links to this valuable info.

Yes I think it would be a good idea to add more info about how to extend the model, and also some more info on usage of "collections" vs "Links -properties".
And I could also not find any information related to my original issue with "too large arrays" in Link-property.
One thing that confuses me in this area is that it seems that Swordfish, which I was expecting to be a "simple" Redfish extension, have chosen a bit different application of Collections. (I´m involved in related thread in the separate Swordfish forum... :-)

BR
/Magnus

My first suggestion is that if you've got a large list of resources to 'reference', that you probably want to see if that's really the proper model for the topic. But yes, large arrays of links are not optimal - you may want to create separate collections for those things.

Look at your software (client) use cases - how will a typical client want to use this data? If you have a large collection that isn't normally consumed as a whole (and only as a filtered set), it may be better to break them into separate collections. And the 'rare' software that wants to see "all those thingys" can do the extra bit of work to gather up the separate collections.

Jeff