Re: some comments on the DWBP draft

Hi Eric,

Thank you very much for your comments and very interesting discussions!

We're gonna write some proposals for new BP based on your comments and
ideas. As soon as it is finished I'm gonna let you know and then we can
discuss the proposals. Below, I tried to summarize the main points of our
discussion and how we're gonna address your comments:

- 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.

- 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?

- 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?

Cheers,
Bernadette


2015-07-31 15:22 GMT-03:00 Erik Wilde <dret@berkeley.edu>:

> 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 |
>



-- 
Bernadette Farias Lóscio
Centro de Informática
Universidade Federal de Pernambuco - UFPE, Brazil
----------------------------------------------------------------------------