W3C home > Mailing lists > Public > public-dwbp-wg@w3.org > October 2015

Re: Webby Data

From: Herbert Van de Sompel <hvdsomp@gmail.com>
Date: Mon, 26 Oct 2015 14:06:08 -0600
Message-ID: <CAOywMHcVxHLruwLXx5tDw-g4FZ5_nSemKo-xRC_qY+XhAtDUog@mail.gmail.com>
To: Bernadette Farias Lóscio <bfl@cin.ufpe.br>
Cc: Erik Wilde <dret@berkeley.edu>, Jeremy Tandy <jeremy.tandy@gmail.com>, Phil Archer <phila@w3.org>, "public-dwbp-wg@w3.org" <public-dwbp-wg@w3.org>, Herbert Van de Sompel <hvdsomp@gmail.com>
hi all,

I provided examples to Bernadette related to Memento and versioning.
It's all hypermedia/REST/HATEOAS along the lines of what Erik

But I think there are very real opportunities in the document to
explicitly promote the (best) practice of providing typed links, eg in
HTTP responses.

For example, Example 8 shows metadata that describes a dataset. But it
does not show how that description can be discovered by a client. This
can be done using a typed link the the HTTP Link header provided when
accessing the dataset URI.

* http://example.org/dataset-001 is the dataset URI
* http://example.org/metadata/dataset-001is the URI of metadata that
describes the dataset

In that case:

=> Discover metadata via dataset

curl -i -H http://example.org/dataset-001

HTTP/1.1 200 OK
Link: <http://example.org/metadata/dataset-001>; rel=“describedby”;
type="some mime type", <http://example.org/metadata/dataset-001>;
rel=“describedby”; type="some other mime type",

=> Discover dataset via metadata:

curl -i -H http://example.org/metadata/dataset-001

HTTP/1.1 200 OK
Link: <http://example.org/dataset-001>; rel=“describes”



On Fri, Oct 23, 2015 at 6:25 AM, Bernadette Farias Lóscio
<bfl@cin.ufpe.br> wrote:
> Hi all,
> Thanks a lot for the great discussion!
> I'd like to make two comments: the first one about versioning and the other
> one about the links.
> As we discussed before in our WG, it is not easy to define when to create a
> new dataset or a new version of an existing one. In the DWBP document we
> give some ideas about this, but the choice is up to the publisher [3]. On
> the other hand, we have BP to tell how to do to deal with versioning. In the
> current version of the document, we have two BP: Best Practice 8: Provide
> versioning information and BP 9: Provide version history. There are some
> vocabularies that we can use to describe the version of a dataset as well as
> the relationship between dataset versions. However, I couldn't find terms to
> describe the modifications of one dataset with respect to its previous
> version. In BP9, we argue that this information should be available. I was
> wondering if we can use the Web Annotations Model to describe this [1]. Does
> it make sense to you? Do you have other suggestions?
> Concerning the links, I agree that it is too ambitious to go into the
> details of hypermedia. However, as Phil proposed, we will have BP saying
> that resources (datasets and data items) should have unique identifiers. We
> also have BP related with how to provide access to datasets [2]. We already
> have a BP that tells to Follow REST principles when designing APIs. Maybe,
> this BP may be improved to cover some aspects related with Eric's concerns.
> What do you think?
> Cheers,
> Bernadette
> [1] http://www.w3.org/TR/annotation-model/
> [2] http://w3c.github.io/dwbp/bp.html#dataAccess
> [3] http://w3c.github.io/dwbp/bp.html#dataVersioning
> 2015-10-16 17:06 GMT-03:00 Erik Wilde <dret@berkeley.edu>:
>> hello jeremy.
>> On 2015-10-09 23:12, Jeremy Tandy wrote:
>>> Now, Eric's point [9] is that there is a "difference between 'web data
>>> only' and the 'web of hypermedia-driven services'" and that "'webby
>>> data' is a necessary but not sufficient condition to have hypermedia.
>>> [which requiresproviding navigational affordances to get things done
>>> with that data."
>>> I see that in the vast majority of cases, the data is accessed via a
>>> service end-point ... even if it is a trivial HTTP Get. But there are
>>> cases where (as I said in point #3 above) that you simply want to use
>>> URIs as identifiers. This clearly is not hypermedia. I wonder if there
>>> are two levels of requirements here? At this point, I'm unable to unpick
>>> this distinction further, but I'm sure it will be relevant in the
>> thanks for pointing this out, and i absolutely agree that there are two
>> levels at play here. one level that's needed for "just data" is the ability
>> to identify resources, and this is what RDF is all about. and generally
>> speaking, non-RDF models may want to use similar policies for identifying
>> (some of their) resources via URI. doing this means that identifiers are
>> context-free and thus globally usable, which is a very valuable thing when
>> you start to combine data of various origins.
>> however, links are a fundamentally different issue. they are not
>> identifiers of data resources, but instead identifiers of hypermedia
>> resources which provide support for interactions. in order to be useful,
>> links must be typed
>> (https://github.com/dret/hyperpedia/blob/master/concepts.md#link-relation-type),
>> so that clients can decide which links to follow to accomplish their
>> application goals.
>> as phil suggested, maybe it is too ambitious for DWBP to go into the
>> details of hypermedia, and why and how it matters. but as i said earlier, it
>> seems to me that in order to make data available on the web, most often
>> there are services associated with it. even if often just rather simple ones
>> such as the ability to page through a collection, or to filter it. providing
>> guidance on how to do this in a webby way would be very valuable.
>> thanks and cheers,
>> dret.
>> --
>> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>>            | UC Berkeley  -  School of Information (ISchool) |
>>            | http://dret.net/netdret http://twitter.com/dret |
> --
> Bernadette Farias Lóscio
> Centro de Informática
> Universidade Federal de Pernambuco - UFPE, Brazil
> ----------------------------------------------------------------------------

Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library

Received on Monday, 26 October 2015 20:06:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 26 October 2015 20:06:38 UTC