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

Re: "Linked Data Basic Profile 1.0 Submission"

From: Martynas Jusevicius <martynas@graphity.org>
Date: Tue, 3 Apr 2012 14:24:34 +0200
Message-ID: <CAE35VmzFFHRkhEA_uSVL0+WVK_XeOmJXofeU+VTh=f3hyFs8Mw@mail.gmail.com>
To: Sandro Hawke <sandro@w3.org>
Cc: public-ldp@w3.org
Hey all,

congrats with this milestone :)
I have a few comments though -- not sure where it's best to post them,
so they just follow here below.

Once again, I think there are too many new conventions, which can be
solved by reusing existing ones (especially in 5.1 Informative

bp:Container class is useful -- however, it seems to serve the same
purpose a sioc:Container:
"Container is a high-level concept used to group content Items
together. The relationships between a Container and the Items that
belong to it are described using sioc:container_of and
sioc:has_container properties. A hierarchy of Containers can be
defined in terms of parents and children using sioc:has_parent and
Can't this be reused or at least integrated somehow? So that the
existing SIOC Linked Data "automagically" becomes (closer to being)
 LDBP 1.0 compliant?
If DublinCore is endorsed in this document, isn't it OK to endorse a
stable and widespread vocabulary such as SIOC? It is already a W3C
member submission [1]. I'm not sure creating another vocabulary for
such a similar purpose is a good idea.

And then I think the whole approach to paging (isn't it called
"pagination" in English?) is quite wrong.
If you think in terms of Containers and Resources, then in my opinion
they can be split into several cases:

1. Item resource, which description only includes subject URIs
identical to the request URI
Usually a result of DESCRIBE query. Linked Data API defines this
concept as api:ItemEndpoint.

2. Container/List resource, which description includes resources other
than request URI.
This is what bp:Container, sioc:Container, and api:ListEndpoint is about.
Description is usually a result of a (SPARQL) query, so this is where
paging applies.

3. Mixed, combining #1 and #2 - e.g. DBPedia returning a description
of a class plus short list of its instances

As #2 (at least in my experience) is derived as a result of a
CONSTRUCT query, so I think some SPARQL terms like LIMIT and OFFSET
can be reused here. For example, instead of

   a bp:Page;
   bp:pageOf <http://example.org/netWorth/nw1/assetContainer>;
   bp:nextPage <http://example.org/netWorth/nw1/assetContainer?p=2>.

we could say:

   a bp:Page;
   bp:pageOf <http://example.org/netWorth/nw1/assetContainer>;
   bp:nextPage <http://example.org/netWorth/nw1/assetContainer?offset=20&limit=20>.

I've used this approach successfully for a long time.
The purpose of the Page concept is not totally clear to me -- isn't it
just another Container (subset of the assetContainer)?

Or better yet, since in RDF everything can be addressed unambiguously,
why can't we identify query string parameters with URIs and map them
directly to SPARQL query parameters?
And here's where I want to bring up the SPIN vocabulary again, which
allows modelling of SPARQL queries in RDF and is also a W3C member
submission [3].
SPIN readily includes properties such as sp:offset and sp:limit, so we
could say:

   a bp:Page;
   bp:pageOf <http://example.org/netWorth/nw1/assetContainer>;
   bp:nextPage <http://example.org/netWorth/nw1/assetContainer?http%3A%2F%2Fspinrdf.org%2Fsp%23offset=20&http%3A%2F%2Fspinrdf.org%2Fsp%23limit=20>.

In my eyes, that would be much less ambiguous and complete the whole
cycle from HTTP query strings to SPARQL query strings by reusing
existing vocabularies.


[1] http://www.w3.org/Submission/2007/SUBM-sioc-spec-20070612/
[2] http://code.google.com/p/linked-data-api/wiki/API_Vocabulary
[3] http://www.w3.org/Submission/2011/SUBM-spin-overview-20110222/

On Mon, Apr 2, 2012 at 9:15 PM, Sandro Hawke <sandro@w3.org> wrote:
> The submission discussed at the workshop has now been acknowledged:
> http://www.w3.org/Submission/
> http://www.w3.org/Submission/2012/02/
> Much thanks to W3C members IBM, DERI, EMC, Oracle, Red Hat,
> SemanticWeb.com, and Tasktop, for their work on this.
> I'll link it into the proposed charter shortly.
>     -- Sandro
Received on Tuesday, 3 April 2012 12:25:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:16:33 UTC