Re: some comments on the DWBP draft

hello bernadette.

On 2015-08-08 13:48, Bernadette Farias Lóscio wrote:
> Last Friday, during the meeting of the DWBP working group, we discussed
> some of your comments about linking data resources. However, we still
> don't have a "concrete" proposal of how to show this as part of the BP.
> Could you please give some examples of how to link data resources
> identified by URIs using hypermedia ?

i have to admit that i am struggling a bit with what exactly you're 
asking here. are you asking me to explain what hypermedia is? the REST 
community has been working on this for about a decade by researching the 
architectural underpinning of the web (our motto always was that we 
focus on how to do data and services in proper web fashion), and of 
course hypermedia as a concept has been around much longer.

while REST is more than just data access, providing access to data is a 
proper subset of what REST is all about, and since REST is the 
architectural style of the web, by adhering to REST, you're being 
properly webby by definition.

if in fact you're asking me to should illustrate hypermedia with an 
example, then i don't want to claim to give an authoritative 
explanation, but maybe i should illustrate it with something simple, 
established, and that's used all over the web.

- http://tools.ietf.org/html/rfc4287 is a hypermedia format that defines 
how to represent collections of resources. 
http://tools.ietf.org/html/rfc4287#section-7.1 defines some link 
relations that specifically say how to link associated resources from an 
atom feed.

- http://tools.ietf.org/html/rfc5005 is not a format in itself, but 
extends atom's hypermedia semantics by introducing new kinds of links. 
clients knowing those link relations can page through paged feeds. 
clients not knowing those links cannot page, because they don't the link 
relations, but they can still process a feed page.

- http://tools.ietf.org/html/rfc5023 is a protocol that introduces even 
more link relations, this time with the goal to allow clients to update 
a feed's resources. again, non-atompub clients cannot do that because 
they don't understand the atompub links, but atompub-capable clients do 
and thus can engage in richer interactions with atompub-capable services.

- commercial specs also picked up on the general utility of atom. 
podcasts, for example, are using atom for exposing feeds of multimedia 
content. the format (defined by apple, iirc) introduces new link 
relations because there are some additional resources clients might want 
to navigate to from a podcast feed. but again, you can point a generic 
atom client at a podcast and it will happily read those parts that are 
not podcast-specific, but use general feed concepts.

- i vaguely remember another feed-based format for exposing feeds of 
published e-books (basically "book podcasts"), so there you have another 
example of how webby hypermedia is nicely composable and can be extended 
as/when required.

this also is a good example of how a lot of webby things is actually a 
mix of a variety of capabilities. this is also why REST is so clear 
about the fact that hypermedia is essential: hypermedia allows to add 
new controls to resource representations (such as atompub links to an 
atom feed) without requiring that all consumers actually support 
atompub: pure atom clients can happily consume atompub feeds, they will 
simply not understand the embedded atompub links. this is exactly what i 
was explaining earlier when talking about versioning: well-defined 
hypermedia doesn't need it.

since link relations are so essential for hypermedia on the web, it 
probably be good to mention IANA's registry 
(https://github.com/dret/sedola/blob/master/MD/linkrels.md is an 
extended version that also includes link relations that haven't yet been 
registered, but have been proposed in a variety of drafts). every 
designer of hypermedia should first look at this list and consider 
building their hypermedia based on those. iff they find their link 
semantics are not adequately represented by any of the existing ones, 
then they can introduce their own, and then many web standards follow 
the convention to identify those "non-standard" link relations via URI 
identifiers (in this case, *the link's type* is identified by URI, which 
might be a bit confusing at first glance, because that's not necessarily 
an actionable URI, but it doesn't need to be, since by definition it's 
only a name and not an actual resource).

i am not sure if i have understood and answered your question, and if 
not, please let me know.


>
> Thank you!
> Bernadette
>
>
>
> 2015-08-05 20:05 GMT-03:00 Erik Wilde <dret@berkeley.edu
> <mailto:dret@berkeley.edu>>:
>
>     hello bernadette.
>
>     On 2015-08-05 15:07 , Bernadette Farias Lóscio wrote:
>
>         - Say something about the use of HTTP conneg or different URIs for
>         different resource representations. This is gonna be addressed
>         by data
>         formats BP or data access BP.
>
>
>     very good. the REST community never got to a preferred way how to
>     deal with this: some prefer HTTP conneg, some prefer different URIs.
>     it would be fine to simply mention those possibilities (and maybe
>     their pros/cons) without necessarily promoting one.
>
>         - Discuss fragment identification (keeping this identification
>         robust
>         across different representations). For this, we need to discuss the
>         concept of resource fragmentation. Could you please indicate some
>         references about this?
>
>
>     https://tools.ietf.org/html/rfc3986#section-3.5 is where they are
>     defined. the gotcha is that their interpretation depends on the
>     media type, so for example for XML, http://www.w3.org/TR/xml-id/ is
>     how https://tools.ietf.org/html/rfc7303#section-5 defines them
>     (well, it's actually XPointer but i'll spare you the details).
>
>         - Discuss the creation of links between resources.  IMO, in order to
>         discuss the creation of links between data resources we need to
>         discuss
>         the principles of linked data and the use of RDF. Do you agree
>         with this
>         proposal or would you like to propose another way of defining links
>         between data resources?
>
>
>     i disagree. linking data is a part of web architecture (the HATEOAS
>     in REST) and independent of specific technologies such as RDF. since
>     most people interpret the term "linked data" as implying RDF, it is
>     too specific for this discussion. my proposal was to start with
>     hypermedia as a concept, and take it from there.
>
>     even if you want to mention RDF, then it would be a bad example
>     because it is not hypermedia. it is a graph data model that needs
>     additional layers (like the ones i pointed to in earlier emails) so
>     that it can be used as hypermedia.
>
>     my proposal is to start with these simple principles, because they
>     are just about how to be webby, without prescribing a technology for it:
>
>     https://github.com/dret/webdata (the key point is the fourth star)
>
>     kind regards,
>
>
>     dret.
>
>     --
>     erik wilde | mailto:dret@berkeley.edu <mailto:dret@berkeley.edu>  -
>     tel:+1-510-2061079 <tel:%2B1-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
> ----------------------------------------------------------------------------

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Thursday, 13 August 2015 00:04:06 UTC