Re: some comments on the DWBP draft

hello bernadette.

On 2015-07-30 9:07 , Bernadette Farias Lóscio wrote:
> 2015-07-28 20:31 GMT-03:00 Erik Wilde <dret@berkeley.edu
> <mailto:dret@berkeley.edu>>:
>     i'll leave it up to you to decide where to best put it, but in my
>     experience working with people looking for web architecture
>     guidance, this is how the question comes up. they have resources
>     they want to serve in multiple formats to make a broader range of
>     consumers happy, and then wonder how to best do that.
> I agree! I'm gonna discuss this issue with other members of the working
> group in order to choose the BP more suitable to explain this.

very good. i guess all of us have different experiences about the 
question that come up, and when/why they come up. this is just one of 
those that seem to be very common, so it would be great to have it at 
least mentioned (with, as i mentioned, the option of saying "we're no 
telling you if you should use HTTP conneg or different URIs for 
different resource representations").

>     let's say you have time series data in XML and RDF. your dataset has
>     fragments that, for example, identify sub-resources of individual
>     days (assuming that the whole resource covers weeks or months). only
>     if the various representations are carefully desgined to work this
>     way will
>     http://example.org/data/week3#day1
>     really identify the data fragment of day 1 within the week1
>     resource. it helps consumers, but takes a bit of effort on the
>     provider side. however, if planned in advance, the effort is minimal.
> In this case, I think you are talking about the identification of
> resources that compose a dataset. The identification section [1] has BP
> for the identification of datasets and versions of datasets. However,
> there is no BP for the identification of resources that compose a
> dataset. Maybe, we can include a BP for this. What do you think?

no, i am talking about the sub-resources, as identified by fragment 
identifiers. this concept is a core concept of web architecture, and i 
always encourage people to think about meaningful and robust fragment 
identification, because this can make resource processing much more 
effective. but *if* multiple representations are served, keeping this 
identification robust across them requires manual effort (which in my 
view is a bug in web architecture, and i think many agree, but that's a 
different issue and we have to deal with what we've got).

i think anybody who's job it is to expose data on the web should be made 
aware of that issue and think about it. maybe they are not using 
fragments, or they decide that it's too much effort to make them robust 
across representations, but it's one of those checkboxes that at least 
should be present on each service design review sheet.

>     the web *is* hypertext, so i am a bit surprised that you want to
>     provide best practices without mentioning the very foundation. and
>     yes, RDF is *one* way to create hypertext, but *only if* people
>     actually use it as hypermedia through additional guidelines such as
>     those provided by linked data. but RDF is just one example and imho,
>     best practices shouldn't prescribe technologies. if people use
>     well-designed XML or JSON hypermedia, that's much better than using
>     RDF that's not hypermedia. thus my comment to recommend the pattern
>     (hypermedia), and not any specific way how to implement it.
> I agree with you that best practices shouldn't prescribe technologies.
> The DWBP document avoids as much as possible to provide a BP based on
> one specific technology. I cited RDF just as an example of how to create
> links between resources.

unfortunately, just citing RDF is unhelpful because RDF does not talk 
about links at all. it's a graph data model that uses URIs as node 
identifiers. if you want to refer to something RDF-ish to illustrate 
links, you have to pick something like linked data, which places 
additional constraints om top of RDF's data model.

> However, I still think that creating links
> between data resources is different from creating links between text
> through hypertext.

not really. by definition, hyper-whatever is about creating links that 
are meaningful to interacting with the set of available resources. 
clients follow links to accomplish application goals, and for that to be 
possible, link semantics need to be well-defined so that clients know 
that one link will fetch a resource and another one will update or 
delete it. that's why the web has a set and a registry of well-known 
link relation types.

while i understand that DWBP is more than just "use REST", REST  covers 
all the basic aspects of how to provide access to data and services in a 
way that is in line with web architecture. when REST was new we gave 
tutorials on this (usually one day, 
http://dret.net/netdret/publications#tutorials has a list), and very 
often we did have a lot of people simply looking for ways how to be a 
good web citizen. ticking off all of the REST constraints is a good way 
to start (and on top of that, of course there's the question of how to 
actually represent the resources and services that you are going to 
provide).

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 |

Received on Friday, 31 July 2015 18:23:35 UTC