[oslc-core] Fw: Issue with the Use of dcterms:title and dcterms:description with oslc:ResponseInfo
Arthur Ryman
ryman at ca.ibm.com
Fri Nov 26 09:57:20 EST 2010
Martin,
I actually like this alternative. I have some comments.
There are really two different reasons why paging might occur 1) the
client has limitations, 2) the server has limitations. The core spec only
is explicit about the client limitations. If a client does not request
paging, and the result exceeds the server limits, then there are two
alternates - the request can fail, or the server can return partial
results and a link to the rest. I think we'd agree that the later is more
friendly and has precedents. Atom works that way, and so does Insight
since it copies Atom. In both cases there is a specified way to link to
the next page without the client initiating a paging request.
I think our spec should be more explicit, i.e. a client SHOULD always
check for an oslc.nextPage property. If we adopted this, then we wouldn't
need the redirects.
Regards,
___________________________________________________________________________
Arthur Ryman, PhD, DE
Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
From:
Martin Nally/Raleigh/IBM at IBMUS
To:
Arthur Ryman/Toronto/IBM at IBMCA
Cc:
oslc-core at open-services.net
Date:
11/25/2010 08:35 PM
Subject:
Fw: [oslc-core] Issue with the Use of dcterms:title and
dcterms:description with oslc:ResponseInfo
I do not believe that the problem with the core spec that you describe
exists. I think the core spec is fine in this area and should be left
alone - I think the current design is superior to the one you propose.
Your description says that the problem arises when the user requests
http://example.org/bugs, and the server decides to respond with only the
first page. In the model upon which the core spec is based, this can't
happen. "The list of bugs" and "the first page of the list of bugs" are
two different concepts and are thus two different resources with two
different URLs, and the server does not have the right to respond with the
representation of one when the other was requested. The URL for "the first
page of the list of bugs" is clearly specified in the core spec - it is
http://example.org/bugs?oslc.paging=true. Although the server may not
respond with "the first page of the list of bugs" when the client asked
for "the list of bugs", it might be acceptable for the server to perform a
302 (or 303) redirect if it decided that the requested resource is too big
to return. An argument against this would be that it is unfriendly to
surprise a client that may not understand paging in this way, but on the
other hand, returning an unworkably large representation might be worse
and so the redirect might be the lesser of two evils. If the server did
perform a redirect to http://example.org/bugs?oslc.paging=true, a
subsequent GET on that URL would produce the following representation
according to the current core spec design:
<rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="
http://open-services.net/ns/core#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.org/bugs">
<dcterms:title>Bug List</dcterms:title>
<rdfs:member rdf:resource="http://example.org/bugs/1" />
<rdfs:member rdf:resource="http://example.org/bugs/2" />
<!-- etc. -->
<rdfs:member rdf:resource="http://example.org/bugs/1000"/>
</rdf:Description>
<oslc:ResponseInfo rdf:about="
http://example.org/bugs?oslc,paging=true">
<dcterms:title>Bug List - Page 1</dcterms:title>
<oslc:totalCount>10000</oslc:totalCount>
<oslc:nextPage rdf:resource="
http://example.org/bugs/pages/2" />
</oslc:ResponseInfo>
</rdf:RDF>
As you can see there is no problem because the two dcterms:title triples
have different subjects.
Best regards, Martin
From:
Arthur Ryman/Toronto/IBM at IBMCA
To:
oslc-core at open-services.net
Date:
11/23/2010 12:47 PM
Subject:
[oslc-core] Issue with the Use of dcterms:title and dcterms:description
with oslc:ResponseInfo
Sent by:
oslc-core-bounces at open-services.net
While reviewing an implementation I noticed that dcterms:title and
dcterms:description can be used with oslc:ResponseInfo. This can lead to
confusion in the case of requesting a any resource, since that resource
itself may use those properties. The resource URI of the first page of a
multi-page response is the same as the URI of the resource itself.
For example, suppose we have a resource that is a list of bugs and that it
has the dcterms:title "List of Bugs". Suppose it contains 10,000 bugs, and
this is too much to return in one response. This resource is like:
<rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="
http://open-services.net/ns/core#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.org/bugs">
<dcterms:title>Bug List</dcterms:title>
<rdfs:member rdf:resource="http://example.org/bugs/1" />
<rdfs:member rdf:resource="http://example.org/bugs/2" />
<!-- etc. -->
<rdfs:member rdf:resource="http://example.org/bugs/10000"
/>
</rdf:Description>
</rdf:RDF>
Suppose the service will only return 1,000 or less bugs per response. When
you get the bug list URI, the response therefore gets paged. The OSLC Core
spec says that the first page looks something like:
<rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="
http://open-services.net/ns/core#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.org/bugs">
<dcterms:title>Bug List</dcterms:title>
<rdfs:member rdf:resource="http://example.org/bugs/1" />
<rdfs:member rdf:resource="http://example.org/bugs/2" />
<!-- etc. -->
<rdfs:member rdf:resource="http://example.org/bugs/1000"
/>
</rdf:Description>
<oslc:ResponseInfo rdf:about="http://example.org/bugs">
<dcterms:title>Bug List - Page 1</dcterms:title>
<oslc:totalCount>10000</oslc:totalCount>
<oslc:nextPage rdf:resource="
http://example.org/bugs/pages/2" />
</oslc:ResponseInfo>
</rdf:RDF>
The issue here is that now there are two dcterms:title triples associated
with the subject node <http:example.org/bugs>, which is confusing since
the second one (a child of the oslc:ResponseInfo element) is really the
title of the response.
I can see two fixes. I prefer fix 1 since it cleanly separates the
response info from the request result data.
1. (Preferred) Introduce another property, e.g. oslc:request to identify
the request URI, and use a blank node for oslc:ResponseInfo. The result is
now:
<rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="
http://open-services.net/ns/core#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.org/bugs">
<dcterms:title>Bug List</dcterms:title>
<rdfs:member rdf:resource="http://example.org/bugs/1" />
<rdfs:member rdf:resource="http://example.org/bugs/2" />
<!-- etc. -->
<rdfs:member rdf:resource="http://example.org/bugs/1000"
/>
</rdf:Description>
<oslc:ResponseInfo>
<oslc:request rdf:resource="http://example.org/bugs" />
<dcterms:title>Bug List - Page 1</dcterms:title>
<oslc:totalCount>10000</oslc:totalCount>
<oslc:nextPage rdf:resource="
http://example.org/bugs/pages/2" />
</oslc:ResponseInfo>
</rdf:RDF>
2. Use different properties for title and description, e.g.
oslc:responseTitle, oslc:responseDescription
<rdf:RDF xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:oslc="
http://open-services.net/ns/core#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="http://example.org/bugs">
<dcterms:title>Bug List</dcterms:title>
<rdfs:member rdf:resource="http://example.org/bugs/1" />
<rdfs:member rdf:resource="http://example.org/bugs/2" />
<!-- etc. -->
<rdfs:member rdf:resource="http://example.org/bugs/1000"
/>
</rdf:Description>
<oslc:ResponseInfo rdf:about="http://example.org/bugs">
<oslc:responseTitle>Bug List - Page 1</oslc:responseTitle>
<oslc:totalCount>10000</oslc:totalCount>
<oslc:nextPage rdf:resource="
http://example.org/bugs/pages/2" />
</oslc:ResponseInfo>
</rdf:RDF>
Regards,
___________________________________________________________________________
Arthur Ryman, PhD, DE
Chief Architect, Project and Portfolio Management
IBM Software, Rational
Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
More information about the Oslc-Core
mailing list