[oslc-core] OSLC Core properties for ui previews - suggested change to Core Spec Appendix A - other places to put the icon metadata
Martin P Pain
martinpain at uk.ibm.com
Thu Nov 14 04:52:30 EST 2013
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: martinpain at uk.ibm.com
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 <johnarwe at us.ibm.com>
To: oslc-core at open-services.net,
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" <oslc-core-bounces at open-services.net>
> 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
Oslc-Core at open-services.net
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20131114/5dc4cfaf/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 518 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20131114/5dc4cfaf/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 1208 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20131114/5dc4cfaf/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20131114/5dc4cfaf/attachment.gif>
More information about the Oslc-Core
mailing list