This wiki is locked. Future workgroup activity and specification development must take place at
our new wiki
. For more information, see
this blog post about the new governance model
and
this post about changes to the website
.
TWiki
>
Main Web
>
MainOslcCommonArchitecture
>
ReportingHome
>
ResourceFormat
(30 Jan 2010,
TackTong
)
(raw view)
---+ Resource Format %TOC% ---++ ---++ Overview The goal of this document is to define extra requirements on the data returned by the RESTful service to enable reporting, details about resources in specific domain will be described in specification for each domain separately. ---++ Identifying properties Each property should be uniquely identifiable. To be more concrete, following are two different ways to organize data, and their implications based on the above assumption. 1. Option 1 If the data is represented in a generic way like this: <literal><pre><attribute></pre><pre> <name>att1</name></pre><pre> <value>value1</value></pre><pre></attribute></pre><pre><attribute></pre><pre> <name>att2</name></pre><pre> <value>value2</value></pre><pre></attribute> <br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br><br></br></pre></literal> We can identify "name" and "value" of the "attribute", we will get a list of generic attributes like this (logically): | name | value | | att1 | value1 | | att2 | value2 | The benefit is, we deal with the attributes in a generic way, this allow us to support new, custom attributes without changes. The disadvantage is, we can't deal with each attribute using specific logic since we can't tell one attribute from the other. 2. Option 2 If the data is like this: <pre><att1>value1</att1></pre><pre><att2>value2</att2> </pre> Then we can identify "att1" and "att2", we will get specific attributes like this (logically) | att1 | att2 | | value1 | value2 | The benefit is, we can deal with each attribute with specific logic. The disadvantage is, we can't support new, custom attributes without changes. ---++ Extracting data The reporting consumer should be able to extract real content for the properties from the resultset directly. That means, the service provider should return real content for properties in the resultset and the reporting consumer shouldn't be forced to follow URLs to retrieve real content for properties. ---++ Identifying resources Each resource MUST be globally uniquely identifiable. Choices for identifier: 1. absolute URI reference ... (other choices?) ---++ Resource deletion Options considered<br />1. soft delete with an indicator marking record as logically deleted.<br />2. add a REST API to get all deleted records since a date-time.<br />3. reporting client to request individual records one at a time to validate existence. <br />4. reporting cleint query to get resource URL (or an unique identifier if exist) for all current records (excluding hard and soft deleted). It would be reporting client's responsibility to map work what has been deleted in its data repository. Option 4 is chosen for * no new REST API needed * performance Note: Service Provider should aware of this use case and optimize if feasible. ---++ Last update date In order to participate in delta loading for changed records, each OSLC resource need to have property dc:modified. The reporting consumer can query on the dc:modified property to get records modified since a date-time. ---++ Paging <a name="paging" title="paging"></a> Proposal: <oslc_rm:Requirements rdf:about="xxx.example.com/Requirements"> <oslc:PageContext<br /> oslc:nextPage="http://xxx.exmaple.com/4563EFA899"/> <!--actual content for Requirements --> </oslc_rm:Requirements> Original email from ArthurRyman : <oslc:PageContext <br /> oslc: *thisPage* ="http://braintwistors.example.com/ems10/Estimate?oslc:select=ems:select=dc:title,dc:identifier&oslc:where=ems:scenario{ems:project{dc:identifier=4201}}&oslc:pageSize=100" <br /> oslc: *nextPage* ="http://braintwistors.example.com/ems10/Estimate?oslc:select=ems:select=dc:title,dc:identifier&oslc:where=ems:scenario{ems:project{dc:identifier=4201}}&oslc:pageSize=100&oslc:page=2"<br /> oslc: *firstPag* e="http://braintwistors.example.com/ems10/Estimate?oslc:select=ems:select=dc:title,dc:identifier&oslc:where=ems:scenario{ems:project{dc:identifier=4201}}&oslc:pageSize=100" <br /> oslc *lastPage* ="http://braintwistors.example.com/ems10/Estimate?oslc:select=ems:select=dc:title,dc:identifier&oslc:where=ems:scenario{ems:project{dc:identifier=4201}}&oslc:pageSize=100&oslc:page=2"<br /> > <br /> <oslc: *select* >ems:select=dc:title,dc:identifier</oslc:select><br /> <oslc: *where* >ems:scenario{ems:project{dc:identifier=4201}}</oslc:where><br /> <oslc: *pageSize* >100</oslc:pageSize><br /> <oslc: *numberOfPages* >2</oslc:numberOfPages><br /> <oslc: *page* >1</oslc:page> <br /></oslc:PageContext> ---++ Comments Add your comments here: Suggest on "identifying properties" List out a potential usage example for each option: e.g. a listing reporting lists all attributes vs. analysing a measure based on a custom attribute as a dimension. -- Main.TackTong - 12 Nov 2009 All REST resource has an URI by definition. I guess the reqt. is do we need the URI to be surfaced as a property of the resource? or we can get from rdf:about? From Reporting System perspective, does it matter what the id is as long as there is one? -- Main.TackTong - 12 Nov 2009 %COMMENT% -- Main.XiangDongHu - 03 Nov 2009
E
dit
|
A
ttach
|
P
rint version
|
H
istory
: r6
<
r5
<
r4
<
r3
<
r2
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r6 - 30 Jan 2010 - 01:30:10 -
TackTong
Main
Main Web
Create New Topic
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
Webs
Main
Sandbox
TWiki
Български
Cesky
Dansk
Deutsch
English
Español
Français
Italiano
日本語
Nederlands
Polski
Português
Русский
Svenska
简体中文
簡體中文
Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our
Terms of Use
Ideas, requests, problems regarding this site?
Send feedback