- From: Herbert Van de Sompel <hvdsomp@gmail.com>
- Date: Wed, 1 Jul 2015 11:30:25 -0600
- To: Erik Wilde <dret@berkeley.edu>
- Cc: "public-dwbp-wg@w3.org" <public-dwbp-wg@w3.org>, Herbert Van de Sompel <hvdsomp@gmail.com>
On Tue, Jun 30, 2015 at 8:36 PM, Erik Wilde <dret@berkeley.edu> wrote: > hello herbert. > > On 2015-06-30 09:50, Herbert Van de Sompel wrote: >>> >>> if you think they're similar but not actually the same, what would you >>> say >>> the difference is? i am still struggling to see it, and if they do remain >>> separate, it might be helpful to better explain how they are different. >> >> Well, the difference is in the nature of the content, by which I mean >> that I have a hard time thinking about a vocabulary as a dataset. But >> other than that, when it comes to versioning, both datasets and >> vocabularies are just resources that can be versioned, and to which >> Memento patterns for version disclosure and version access can be >> uniformly applied. > > > that's funny, i have a hard time thinking about a vocabulary *not* being a > dataset. metadata is data, too, it's all a question of perspective. so > there's no need to make any special rules for something that in some context > happens to be metadata. many publishers may choose to not expose > vocabularies in the same way as data (because for example they may not have > control over them), and i think that makes a lot of sense, but if they do > choose to publish them as data, normal rules apply. > I think we agree regarding the essence: the same versioning patterns can be applied to data, vocabs. I remember you making a comment about API versioning. API descriptions, e.g. using RESTdesc (http://restdesc.org/about/descriptions), could be versioned using the same pattern. >> Overall, I think I should be happy with the fact that Memento is being >> mentioned with regard to versioning. On the other hand, I am not sure >> why alternatives such as: >> - the use of an "API for version access" mentioned Best Practice 8 >> - the use of an "API for access to version history" mentioned in Best >> Practice 9 >> should be promoted, understanding that there is an RFC (7089) (which >> was 4 years in the making) that provides - IMO - all the required >> capabilities and is fully aligned with REST, follow-your-nose. I guess >> this question is related to what the ultimate goal of this document >> is. > > > memento *is* an API, right? so some may choose memento, others may > choose > other things. BP documents should stay away from starting to recommend > specific technologies, that usually leads to a lot of fighting by technology > owners/creators to get their techs in. so i think you're in good shape > there! > agreed. your comment relates to my question about the goal of the doc. and I tend to agree that a BP doc should probably not recommend specific technologies. at the same time, they need to give sufficient/meaningful guidance. >> Maybe Memento is not understood well enough yet. So, maybe it is not >> clear to many how it addresses all these versioning requirements. I >> would be most happy to provide additional information, if that would >> be considered helpful. > > > like i said, i think you're in good shape there. memento is an RFC which is > great, and if people try to follow BP, they should be smart enough to > discover it as one way to solve some of the problems mentioned in the > document. > OK > what concerns me more right now is the lack of a webby perspective. > curiously, the current WD does not even mention the terms "hypertext" or > "hypermedia", which i find rather odd for a document that tries to define > best practices for publishing anything on the web. the current spec is > really more *what* to put *on* the web, not so much about *how* to make > something to be part *of* the web. > > to some extent, that's what linked data is doing, but then again, that's > something that champions a specific set of techs, which like i said probably > shouldn't be part of any BP. this is the reason why i started this little > project here, which i should probably switch from being a repo to being an > actual page/site: > > https://github.com/dret/webdata > I think this is actually very nice, as you indicate, in the way it is technology-neutral. (looks like it's only us talking currently) Cheers Herbert > it's basically talking about how to be nicely webby data, without making any > assumptions which tech you should choose. > > and since hypermedia is such a central part of being webby, another little > project is here, which tries to classify the ways in which data can be > hypermedia-ish (ie, webby), and then lists some formats. this one needs a > lot work (and probably more structure), but i think it can help people a lot > to better understand how to make data properly webby, without having to > reinvent the wheel: > > https://github.com/dret/hyperpedia > > i hope i will get some feedback about the issues i raised, in particular the > curious absence of webbiness in the current WD. i think it would be great to > better explain to people that making data webby is a better BP than just how > to make your data available for download. > > 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 | -- Herbert Van de Sompel Digital Library Research & Prototyping Los Alamos National Laboratory, Research Library http://public.lanl.gov/herbertv/ ==
Received on Wednesday, 1 July 2015 17:30:54 UTC