My thoughts on this are that: If multiple resources have the same icon, all information to display it should be available in N+1 GETs. (N+2 or some other small number would be acceptable)
In other words, the number of requests required shouldn't be a multiple of the number of resources, unless they all have visually different (or semantically different) icons. (More like the number of resources plus the number of distinct icons.) As it currently stands the consumer has to: 1) Request the main representation for all resources (N requests) 2) Request the compact representation for all resources (N requests) 3) Request each icon (I requests, where I <= N) - although this may be done by a user's browser This results in 2N+I requests. I have two thoughts on how fewer requests could be achieved: Option (1): by providing a URI to the icon (either to the icon file itself or preferably to an oslc:Icon resource - we should choose one of these approaches in the the spec) in the resource representation. e.g: @base http://example.com/. <r1> # ... standard properties for this resource oslc:icon2 [ a oslc:Icon; oslc:icon <icon1.png>; oslc:iconTitle "Icon1"; ] . Which would result in: 1) Request the main representation for all resources (N requests) 2) Look at the oslc:Icon resource for all resources (zero requests - it's inline) 3) Request each icon (I requests, where I <= N) - although this may be done by a user's browser This results in N+I requests, which is almost half the number required on the existing method. or it can be done in two separate requests: GET http://example.com/r1 @base http://example.com/. <r1> # ... standard properties for this resource oslc:icon2 <icon1rdf>; #icon-specific URL, not resource-specific . GET http://example.com/icon1rdf @base http://example.com/. <icon1rdf> a oslc:Icon; oslc:icon <icon1.png>; oslc:iconTitle "Icon1"; . Which would result in: 1) Request the main representation for all resources (N requests) 2) Look at the oslc:Icon resource for all resources (I requests, where I <= N, as many resources will share an icon) 3) Request each icon (I requests) - although this may be done by a user's browser This results in N+2I requests, which is less than the number required on the existing method. Option (2): Have some means for mapping from a resource to an icon, by which the input to that mapping is not the URI of the resource, and allows the result to be cached e.g: @base http://example.com/. <serviceProvider> oslc:iconResolver [ oslc:forType <some resource type that has icons>; oslc:inputPropertyForResolution x:state rdf:type; oslc:resolutionUrl <iconResolver> ] . meaning: * This service provider may be able to provide an icon for resources that have the '<some resource type that has icons>' term as a value of rdf:type. * The icon is based solely off of the x:state and rdf:type values of the resource (and the icon can be cached based on these values and the HTTP response headers when retrieving the icon). * The icon is retrieved by sending a request to the '<iconResolver>' URL specifying the value of the x:state and rdf:type properties of the resource in question (using some protocol that the spec must define) and the server response points to the icon using the 'Location' HTTP header. Which would result in: 1) Request the main representation for all resources (N requests) 2) Get the representation for each service provider for these resources (likely one or zero requests, as the consumer may already have these details) 3) Send a request to the iconResolver URI for each unique set of values for the properties specified by oslc:inputPropertyForResolution (I requests, where I <= N, as many resources will have the same set of values for those properties) 4) Request each icon (I requests) - although this may be done by a user's browser This results in N+2I requests, which is less than the number required on the existing method. I don't suggest we go with this, but if we wanted to then it provides a way to: * Avoid the GET on the compact representation for every resource to render. * Not put the icon details in the main representation (as it is not a definitive part of the data, and might not make sense to index) (Any of these approaches could also be used with sprites) Kind regards, Martin Pain Software Developer - Green Hat Rational Test Virtualization Server, Rational Test Control Panel Open Services for Lifecycle Collaboration - Automation WG joint chair E-mail: [email protected] Find me on: and within IBM on: IBM United Kingdom Limited Registered in England and Wales with number 741598 Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU From: John Arwe <[email protected]> To: [email protected], Date: 06/11/2013 20:12 Subject: Re: [oslc-core] OSLC Core properties for ui previews - suggested change to Core Spec Appendix A Sent by: "Oslc-Core" <[email protected]> > 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. *That* would be useful scenario-words for inclusion in the same document IMO. > 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. No objection. This could be read also as "people don't know what vocabularies are out there for re-use". I know that's something I pay serious attention to when reviewing their work, and I push them hard to re-use not add-new. Clearly(?) "just toss it into Common" does not scale well. > For completeness, we > should probably include oslc:iconAltLabel and oslc:iconTitle. You lost me at "For completeness". Either it's meets-min for the scenarios we're saying should be supported or it's not. I've taken the position before that we're just pretending these are independent properties instead of grouping them as an icon resource (which would argue for keeping them together by definition), but Core wasn't enamored with that. > 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. In our implementations, the UI people have been very vocal about the "extra" round trip needed. Your reasoning assumes that "most" resources actually have previews (in which case it's a toss-up, granted). Once you have "enough" links to resources outside of OSLC space (or inside it but lacking previews), they assert that hitting them all *just to find out if a UI preview exists* for each becomes a responsiveness/scale issue. Looking at the UI preview spec, those preview predicates seem to me to be over-constrained. IIRC "local inline" ==> blank node, but the real intent is just that their content comes back along with the compact representation. In 3.0 (waves to Sam) we should directly state that instead of ruling out addressable URIs (e.g. hash URIs) as a way to force content we want. It seems every bit as reasonable to include the small/largePreview links (optionally) in common properties as it does to include oslc:serviceProvider or oslc:instanceShape. At that level, I would not constrain them to be represented as blank nodes (of course?). If they're absent a client is no better/worse off than today; if they're present, a client can be "pretty sure" that the resource offers a UI preview, and if retrieving any of them in effect retrieves all of them "ok - so what's the problem?" Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
