W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

Re: How to request for the number of members of a container ?

From: Alexandre Bertails <bertails@w3.org>
Date: Tue, 20 Nov 2012 09:27:04 -0500
Message-ID: <50AB9338.8000801@w3.org>
To: Steve K Speicher <sspeiche@us.ibm.com>
CC: Olivier Berger <olivier.berger@it-sudparis.eu>, public-ldp-wg@w3.org
On 11/20/2012 08:29 AM, Steve K Speicher wrote:
>> From: Olivier Berger <olivier.berger@it-sudparis.eu>
>> To: public-ldp-wg@w3.org,
>> Date: 11/19/2012 04:38 PM
>> Subject: How to request for the number of members of a container ?
>> Hi.
>> I cannot seem to quickly find a mention on how one may "query" a LDP
>> Container for it's number of contained members/Resources... (call it
>> count / len(gth) "primitives", if you will) :-/
>> I don't have my printed copy of the specs at hand to check and couldn't
>> spot an easy answer browsing the HTML document.
>> Is this worth an Issue or am I missing the obvious ?
> The idea is that this number would be ever evolving, especially with
> pagination, therefore a meaningful number would be hard to maintain.  As
> for the number of members of a container that you have in hand, it is
> usually best to rely on software library (like length()) or manually count
> to give you an accurate number.  If the server return it with the
> representation, then the client would still be left to deal with the fact
> when the numbers are different (computed vs. given).  So I believe leaving
> it off might be best.

What I'm doing *right now*: I consider the LDPC as yet another SPARQL
endpoint (no UPDATE, only SELECT, CONSTRUCT and ASK) which identifies
all its LDPR to named graphs.

So I could get the answer with a simple SELECT COUNT.


> One could argue the point that we could raise an issue, reach this
> conclusion, then no spec action is taken.  At least then we'd have it
> "recorded".
> Thanks,
> Steve Speicher
> IBM Rational Software
> OSLC - Lifecycle integration inspired by the web ->
> http://open-services.net
Received on Tuesday, 20 November 2012 14:28:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:42 UTC