For performance reasons, it is desirable that a single http GET request on a resource provided all the information necessary for a human-readable summary about that resource, and that a query can get all the information necessary for a human-readable display of a table of the results.
The common properties defined in Appendix A of the Core 2.0 spec, http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA, include many properties that help with this, including for example oslc:shortTitle. Unfortunately, there is one key omission: oslc:icon. The oslc:icon property is defined as part of the compact representation of a resource in the Core IU Preview page at http://open-services.net/bin/view/Main/OslcCoreUiPreview, and is also listed as a property of the publisher property of the service provider and service provider catalog resources, but is not included in Appendix A as a common property. Many OSLC domains have taken the set of properties listed in Appendix A as the basis for defining the recommended properties for that domain; the result is that few (if any) OSLC resources today include the oslc:icon property in the standard representation, but include it only in the compact representation. The consequence is that an application that wants to show the icon in a query results table has to perform an additional GET to read the compact representation. I propose that we add oslc:icon to the list of common properties in Appendix A, and recommend its inclusion in the standard set of properties of OSLC resources from all domains. For completeness, we should probably include oslc:iconAltLabel and oslc:iconTitle. I do not believe it is necessary to include oslc:smallPreview or oslc:largePreview in the Append A list, since we would not want the actual preview contents to be included in the default representation of a resource; we want that to be obtained by a separate GET. We could achieve that by including these two preview links in the Appendix A properties, but with the recommendation that they be normal externally referenced resources with an http URL - but that has no performance advantage over the current technique of having those previews embedded as inline resources in the compact representation, and has the disadvantage of requiring these resources to have an externally addressable URL. Nick Crossley.
