[oslc-core] OSLC Core properties for ui previews - suggested change to Core Spec Appendix A

[John Arwe]

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20131106/88521ad2/attachment-0003.html>