Re: [lyo-dev] How to optimize retrieval of ResourceShapes

[Samuel Padgett <spadgett@xxxxxxxxxx>]

Nils,

Query capabilities can provide a general shape of what the resources returned look like. Maybe this is what you need?

http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;up=#Query_Capabilities

This won't be as specific as an instance shape, which might be different given the current state of the resource.

--
Samuel Padgett | IBM Rational | spadgett@xxxxxxxxxx
Eclipse Lyo: Enabling tool integration with OSLC


Nils Kronqvist ---09/04/2013 04:47:30 AM---Hi, As I understand it, one difference between OO's relation between instances of a class and the Cl

From:	Nils Kronqvist <nissekronqvist@xxxxxxxxxxx>
To:	Lyo developer discussions project <lyo-dev@xxxxxxxxxxx>
Date:	09/04/2013 04:47 AM
Subject:	[lyo-dev]  How to optimize retrieval of ResourceShapes
Sent by:	lyo-dev-bounces@xxxxxxxxxxx

---

Hi,

As I understand it, one difference between OO's relation between instances of a class and the Class, and rdf's relation between Resource and it's optional ResourceShape, is that the ResourceShape can be unique for a specific Resource. E.g. if trying to get the http://open-services.net/ns/core#occurs value for a specific Property of Resource A, I have to get the ResourceShape for A and check the occurs value. 

In case you are retrieving a list of resources and want to check properties for each resource, it's a significant cost to have to retrieve the ResourceShape for each resource. In my case, using RTC's OSLC CM, the rdf for the ResourceShape of a ChangeRequest takes about 600ms to read, where the Resource takes about 100ms. 

Any room for implementation shortcuts here? 

You could look for the rdf:type and in case of ChangeRequest also for dcterms:type - very likely that a ResourceShape from the same ServiceProvider, for the same rdf:type and dcterms:type will have the same Property definitions. So in this case you *likely* can cache the ResourceShape. Does NOT feel robust however. 

Or you have to limit what you can assume about the resources retrieved, rethinking some presentation options when dealing much data retrieved. Making it less usable though. 

Other options?

Rgs,

/Nils K _______________________________________________
lyo-dev mailing list
lyo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/lyo-dev