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: Mon, 9 Apr 2012 19:06:59 +0200
Message-ID: <CAE35Vmy+W5e-3Pu_6PUKrk-gppMjakmfNEPb7KWqXrj1oBtS3A@mail.gmail.com>
To: Steve Speicher <sspeiche@gmail.com>
Cc: Sandro Hawke <sandro@w3.org>, public-ldp@w3.org
Hey Steve,

I realized afterwards this might not be the best place to comment on
the member submission.

Is the working group created and is it possible to join it? The
submission says only "we suggest that the Consortium proceeds with the
creation of such a Working Group". Team Comment on the other hand
says: "Continuing discussion of this topic is welcome on the mailing
list public-ldp@w3.org".

I would be happy to provide comments, but am somewhat lost when it
comes to W3C internal processes.

Martynas
graphity.org

On Mon, Apr 9, 2012 at 6:07 PM, Steve Speicher <sspeiche@gmail.com> wrote:
> Hi Martynas,
>
> This mailing list is used for discussion on the charter and not on the
> member submission.  I think it would be great if you could join a working
> group that looks to take the referenced member submission and provide this
> feedback at that time.  With that I resist the temptation to start up a
> response thread on the items you raise.  Look forward to discussion within
> the working group.
>
> Thanks,
> Steve
>
> On Tue, Apr 3, 2012 at 8:24 AM, Martynas Jusevicius <martynas@graphity.org>
> wrote:
>>
>> 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
>> section).
>>
>> 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
>> sioc:parent_of."
>> http://rdfs.org/sioc/spec/#term_Container
>> 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
>>
>> <http://example.org/netWorth/nw1/assetContainer?firstPage>
>>   a bp:Page;
>>   bp:pageOf <http://example.org/netWorth/nw1/assetContainer>;
>>   bp:nextPage <http://example.org/netWorth/nw1/assetContainer?p=2>.
>>
>> we could say:
>>
>> <http://example.org/netWorth/nw1/assetContainer?offset=0&limit=20>
>>   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:
>>
>>
>> <http://example.org/netWorth/nw1/assetContainer?http%3A%2F%2Fspinrdf.org%2Fsp%23offset=0&http%3A%2F%2Fspinrdf.org%2Fsp%23limit=20>
>>   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.
>>
>> Martynas
>> graphity.org
>>
>> [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 Monday, 9 April 2012 17:07:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 17:07:29 GMT