Hiya,
I'd just like to add a few bits about why Linked Data is or was
important. It's not really about sharing the data anymore, it has
become almost a secondary nice to have feature of meta data; surely
you give out the meta data in order to make things findable? No, the
real importance of why the library world should have been quicker and
smarter about it is about namespace real-estate, and the power of
identifiers, and it's this subtler connection in which things are
truly found.
Hmm, what now? Well, whenever we talk about Linked Data or semantic
web or semantic technologies or even distributed data or global data
sets or data services or ... well, any of the technologies we will use
for sharing and re-suing data and meta data in the future - which is
rather large in scope! - in order to make sure we're talking about the
same things, we use namespaces and identifiers.
So, for example, we want to talk about Mark Twain. I could link my
data to a URI (which is just a string of letters to make up an
identifier; that it's a URI that you can plonk in a browser or do a
HTTP GET on to resolve it is an added bonus) so that we can make sure
that when I talk about Mark Twain, I mean the Mark Twain that is
linked to this one ;
http://id.loc.gov/authorities/names/n79021164
And wouldn't it be great if that was the case? It's great that the
library world has an identifier for someone important, and others can
use this same identifier to get some semblance of identity parsing
with some degree of authority.
However, because these identifiers were slow to market, limited in
scope, sometimes hard to find, harder to get a normalised answer, slow
to adopt and US government centric, too much or too complex contextual
data, we instead mostly use ;
http://en.wikipedia.org/wiki/Mark_Twain
Note also that the latter is easy for us humans to identify, and hence
easy to quickly error check ourselves; no resolving needed (and I
could write a whole book on this subject alone, but, some other time).
Why is that?
Well, the library hasn't got (or at least didn't) identifiers for
other things of interest. What will people choose? Identifiers across
many sources, or a global distributed one? The library world's
reluctance to deal with anything not in the scope of books (or, I
should say, their collections, of course) and the rather peculiar
reluctance to open up things like LCSH or other means of
categorisation to the world, people started to use dbpedia and
wikipedia instead. Who has the time to wait for the library world to
make up their mind?
And so you won't be important to the namespaces of the future. And
that is another bit where you could have been the best possible
solution to a lot of difficult identity problems, but are no longer in
the running, and that breaks my heart a little because I think the
libraries would be so much better at it, even baking FRBR concepts
into it for some real funsies. Some don't think much of the power of
these namespaces, but they are; who builds the net of the future? Not
user, but system people, and where do system people go for their
identifiers? Established norms. Oh well.
Regards,
Alex
On Sat, Oct 12, 2013 at 10:32 PM, James Weinheimer
<weinheimer.jim.l_at_gmail.com> wrote:
> On 10/11/2013 10:59 AM, Owen Stephens wrote:
> <snip>
>
>> It would be useful if you could share examples of what you see as a good
>> approach to doing linked data in libraries. The vast majority of linked data
>> examples I'm aware of are created from existing library catalogue data, and
>> as such aren't created from 'FRBR-style' records. However, there is a
>> tendency (only a tendency, not a necessity) to try to link similar things
>> when you do linked data, so some of the projects do end up with aspects of
>> FRBR in their linked data - but this is despite, not because of, the record
>> sources. (similarly some discovery products attempt to group records along
>> FRBR lines - again using data available in MARC records rather than changing
>> the underlying cataloguing standards).
>
> </snip>
>
> I agree with you. I cannot show you FRBR-style records because they don't
> exist as yet. That seems to be one of the main purposes of the Bibframe
> project going on now. The idea is to enact linked data for different parts
> of the current bibliographic record by splitting current records into the
> entities "work" "expression" "manifestation" and "item". Currently,
> everything is based on the manifestation record, which carries all of the
> related entity information. Splitting it would turn our current flat files
> into separate "entities" that will then be linked. Bibframe seems to be
> going another way, apparently avoiding "work" (I think).
>
> But as you mention, there are other ways to do it. I think the FAO project
> is as good a model as any to start with. First, FAO does not follow RDA,
> AACR2 or even ISBD since they have their own cataloging rules. From my own
> understanding of it, for the format of the bibliographic records (yes, there
> are records) it uses primarily Dublin Core, but includes BIBO and some
> elements from other schemes, along with one or two of its own.
>
> For the actual linked data, it uses at least AGROVOC, their agricultural
> thesaurus now which is also linked open data with links into other thesauri,
> e.g. Eurovoc and apparently even LCSH now.
> http://aims.fao.org/standards/agrovoc/linked-open-data A lot of the rest of
> OpenAgris seems similar to federated searching.
>
> Again, if the purpose of all of this is "access" or "resource discovery",
> then it seems that ultimately, you want someone to discover and *click on a
> link* that leads to you and your information. Then you can "wow" them with
> all of your fabulous resources, perhaps linked in with other wonderful
> information. If this is accepted as the basic purpose of linked data
> (resource discovery in some way shape or form), there is a lot of
> information in a MARC record that does not need to be exported, so both the
> format and export could be radically simplified. To begin with, our records
> could be exported much as FAO has done, using DC and terms from other
> schemes, and if something in a MARC record doesn't really fit, then just
> don't export it.
>
> As Bernhard points out, there are some parts of our records that could also
> be linked, e.g. names and subjects into id.loc.gov. That service now seems
> to have a few links into other thesauri but again, when it comes right down
> to it, I don't know how useful all of this would be to the majority of
> users.
>
> It is certainly worth a try, though.
>
>
> --
> James Weinheimer weinheimer.jim.l_at_gmail.com First Thus
> http://catalogingmatters.blogspot.com/ First Thus Facebook Page
> https://www.facebook.com/FirstThus Cooperative Cataloging Rules
> http://sites.google.com/site/opencatalogingrules/ Cataloging Matters
> Podcasts http://blog.jweinheimer.net/p/cataloging-matters-podcasts.html
--
Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
--- http://shelter.nu/blog/ ----------------------------------------------
------------------ http://www.google.com/profiles/alexander.johannesen ---
Received on Sun Oct 13 2013 - 01:27:39 EDT