Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [lyo-dev] How to optimize retrieval of ResourceShapes
Thanks for quick replies - some comments below:

/Nils

Sam Padgett wrote:

==
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.
==

[Nils] It's exactly the "might be different" that worries me. Looking for the predictable logic here; say you have a Resource returned by a query. You can then use the query shape to get metadata for the result - but does it apply to all instances? There is nothing in the spec that prevents a returned resource to have an instance shape pointing to a Property which is contradicting one in the query shape - right?


On 4 sep 2013, at 15:48, Steve Speicher <sspeiche@xxxxxxxxx> wrote:

Hi Nils,

Does it take 600ms to fetch the resource shape and parse each time?
[Nils] Note: the 600ms was reported in the Google REST client - I guess the ratio 6:1 to retrieving the actual Resource was what caught my eye. In actual code it's faster, retrieving 60 resources + instance shapes about 20s.

One alternative is to simply to keep a local cache of the ResourceShapes as they do not vary much from the resources themselves.  Instead of fetching directly from RTC, you just look up from your local cache (assuming the key would be the URL for the ResourceShape).
[Nils] Unfortunately the url includes a UUID so unique per ResourceShape. I tried a similar approach though -- I cached the first instance shape retrieved, and indexed it's Properties based on identifier (uri). The for subsequent Resource fetches - as long as the properties I needed metadata for was in this index - no need for getting another ResourceShape. Worked - but again; as I see it not predictable enough, right. (And BTW did not get expected performance gain .. so might be other issue as well.)

Some experimental results: two work items, both of type Story - but different instance shape urls - and also (for a sample shape property, duplicateOf), different url's for the property definitions. Same info in both property definitions (the 99.99% case I guess) - but no predictable way of knowing without checking .. 

Workitem 132

<dcterms:type rdf:datatype="http://www.w3.org/2001/XMLSchema#string"]]>
Story
</dcterms:type]]>



Workitem 117

<dcterms:type rdf:datatype="http://www.w3.org/2001/XMLSchema#string"]]>
Story
</dcterms:type]]>




I'd need to do some testing with RTC and possibly some other implementations to see how much they really vary their shapes per resource.  You can do an occasional GET/HEAD on the shape to see if it has changed to keep your cache fresh.  You might be able to break things apart in the resource shape and reuse this cache for these pieces, property definitions, vocabulary terms, etc as they all should be URL addressable and therefore cacheable.

- Steve Speicher


On Wed, Sep 4, 2013 at 4:46 AM, Nils Kronqvist <nissekronqvist@xxxxxxxxxxx> wrote:
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


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

Back to the top