 |
 |
On 29/08/12 19:46, Michael Hopwood wrote: > Thanks for this pointer Owen. > > It's a nice illustration of the fact that what users actually want (well, I know I did back when I actually worked in large information services departments!) is something more like an intranet where the content I find is weighted towards me, the "audience" e.g. the intranet knows I'm a 2nd year medical student and one of my registered preferred languages is Mandarin already, or it "knows" that I'm a rare books cataloguer and I want to see what "nine out of ten" other cataloguers recorded for this obscure and confusing title. Yet another re-invention of content negotiation, AKA RFC 2295. These attempts fail because 99% of data publishers care in the first instance about the single use before them and in the second instance the precedent has already been set. The exception, of course, is legally mandated multi-lingual bureaucracies (Canadian government for en/fr; EU organs for various languages etc) and on-the-wire formatting (for which it works very well) > However, this stuff is quite intense for linked data, isn't it? I understand that it would involve lots of quads, named graphs or whatever... > > In a parallel world, I'm currently writing up recommendations for aggregating ONIX for Books records. ONIX data can come from multiple sources who potentially assert different things about a given "book" (i.e. something with an ISBN to keep it simple). > > This is why *every single ONIX data element* can have option attributes of > > @datestamp > @sourcename > @sourcetype [e.g. publisher, retailer, data aggregator... library?] > > ...and the ONIX message as a whole is set up with "header" and "product record" segments that each include some info about the sender/recipient/data record in question. Do yo have any stats for how many ONIX data elements in the wild actually use these elements in non-trivial ways? I've never seen any. cheers stuart -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/