- From: Phil Archer <phila@w3.org>
- Date: Wed, 14 Oct 2015 19:48:42 +0100
- To: Erik Wilde <dret@berkeley.edu>, public-dwbp-comments@w3.org
- Cc: "Tandy, Jeremy" <jeremy.tandy@metoffice.gov.uk>
Hi Erik, In don't disagree with any of what you say, as I imagine others won't either. The problem is the usual one of scope and group capacity. Splitting datasets up into different sections, linked by meaningful relationships etc. is going to be well beyond the ken of most people for whom saving a spreadhseet as a CSV file is a major break from the norm. It's that end of the spectrum we're aiming at here. I really think the ideas you, Ruben, Markus and others express around hypermedia, including the excellent work on Hydra, need a separate WG to take it forward properly. Linking off to something else would be good here for DWBP. It's for the WG, under the guidance of the chairs, not me, to decide whether they wish to pursue the idea of a Note on the topic but I'm going to go all W3C staff on you here (you know what I'm going to say before I say it). The Hydra CG exists (https://www.w3.org/community/hydra/) - if that group of 144 people includes people who: 1. represent W3C members; 2. have the time and commitment to form a full WG and create Recommendations - good. I'd do all I can as Data Activity Lead to make that WG happen. But I think the DWBP as currently constituted and chartered would have difficulty taking the work forward itself (as would the SDW WG btw). Meanwhile I'd be grateful if you could offer such edits as are required to correct this paragraph and to meet the necessary without getting into a full blown detail about the sufficient: These ideas are at the heart of the 5 Stars of Linked Data where one data point links to another, and of Hypermedia where links may be to further data or to services (or more generally 'affordances') that act on or relate to the data in some way. Examples include a bug reporting mechanisms, processors, a visualization engine, a sensor, an actuator etc. In both Linked Data and Hypermedia, the emphasis is put on the ability for machines to traverse from one resource to another following links that express relationships. As for a better home than GitHub for your doc, I'll enquire internally whether I can work with you to turn it into a Team Submission or something similar. Cheers Phil. On 13/10/2015 20:39, Erik Wilde wrote: > hello phil. > > On 2015-10-10 00:40, Phil Archer wrote: >> On 09/10/2015 22:53, Erik Wilde wrote: >>> thanks a lot for getting the discussion about "web data" going (again). >>> we're probably getting closer, but i think we still have a bit of a >>> difference in perspective, because "webby data" is a necessary but not >>> sufficient condition to have hypermedia. >> True. But I don't think we're trying to define hypermedia any more than >> we're trying to define Linked Data. So for me, if we've met the >> necessary part, that's good. It's because we clearly weren't doing that >> that there has been a problem. > > i hope i did not sound as if i wanted to define hypermedia. i was mostly > struck by the fact that the web first and foremost is a > hypermedia-driven information system, and that the document never > mentioned the term or described that hypermedia is what should be > driving any services that are provided to provide access to data. > >>> the difference is that hypermedia is not (only) about linking data >>> (i.e., using "web data"), it's also about providing navigational >>> affordances to get things done with that data. this means that the links >>> are about *services* (or whatever you might call this). >> Yes, OK, I can add a line about that. > > thanks. it might also be worthwhile to highlight the importance of > resource granularity, because that's what deciding interaction granularity. > > if you partition your data into more resources, you need more links, but > you also may provide better ways for people to interact (GET or update > or DELETE) with specific parts of your dataset. > > it's up to the service designers to decide *how* they want this > interaction granularity to look like, but that's one of the really > important things to consider when designing web services. > > granularity is a more natural thing to consider for some metamodels, and > maybe not to much for others. but that's just a side-effect of how those > metamodels work. in the end, what really should drive this is the > intended *service granularity*. > > http://dret.typepad.com/dretblog/2009/05/rest-and-rdf-granularity.html > >> OK, so how about this (which I've included now in my proposed changes at >> [1]. >> "These ideas are at the heart of the 5 Stars of Linked Data where one >> data point links to another, and of Hypermedia where links may be to >> further data or to services (or more generally 'affordances') that act >> on or relate to the data in some way. Examples include a bug reporting >> mechanisms, processors, a visualization engine, a sensor, an actuator >> etc. In both Linked Data and Hypermedia, the emphasis is put on the >> ability for machines to traverse from one resource to another following >> links that express relationships." > > data and services are different things. you can do hypermedia in any > metamodel (if you want to do it with RDF, hydra is a good starting > point). and just by doing linked data, you're not doing hypermedia yet > (which is my hydra is such a neat thing). > > from my experience, it helps a lot to clearly and cleanly separate the > issues of data and services. because then you can first talk about > *what* to provide, and then *how* to provide it. and these are two > different design decisions to make. often, the *what* is already decided > (because the data model is a given), but then the delivery architecture > (the *how*) still matters, and will have an impact in questions such as > whether i can identify subresources in robust ways, so that i can for > example submit issues/bugs about them. > >>> On 2015-10-09 11:28, Phil Archer wrote: >>>> We had a BP that said "use persistent URIs as identifiers". And >>>> then it >>>> said *Datasets* must be identified by persistent URIs. What it didn't >>>> say was that data points within the data should also be URIs where >>>> possible. >>> like i said above, i think talking about "web data" would be a great >>> first step (and thus i am very much in favor of it), but it's not the >>> full hypermedia story, which is *not just* about data. > > i think this really is my main message: by putting "data on the web", > you're deciding to deliver data through a hypermedia-driven service > system. anybody making claims how to best do that has to address both > the "data design" and the "service design" level. > >>>> @Erik - is that doc going to stay on GitHub? Any chance it might find a >>>> more stable/permanent home? I really don't like linking to GH in a W3C >>>> Rec track document. >>> i'd be more than happy to (a) move this to some other place, and/or (b) >>> work on it to make it a bit easier to understand, or maybe add more >>> examples. i am open for suggestions what might be a better home for it. >>> for now i thought that maybe github is not such a bad place, at least as >>> long as this is mostly intended to be a starting point for a discussion >>> around "web data" in general. >> How about a Member Submission?? > > i am not affiliated with a member org right now, but i'd be more than > happy to turn this into some kind of NOTE. which might also have the > added benefit of getting more feedback before the final version. > > thanks and cheers, > > dret. > -- Phil Archer W3C Data Activity Lead http://www.w3.org/2013/data/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Received on Wednesday, 14 October 2015 18:48:48 UTC