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/
