Quoting Weinheimer Jim <j.weinhei...@aur.edu>:
But it is my understanding that you can go through a database to get
to the data,
Jim, while you can get into databases through interfaces that are
found on the web, that data cannot openly interoperate with web data,
nor can it be indexed in search engines. So the linked data that is
being discussed for the semantic web is data ON the web, not in a
closed database that is accessible from a controlled web interface.
and as a result a URI includes the OpenURL. This is a
"relative reference URI", where you have to establish a base URI.
See > http://tools.ietf.org/html/rfc3986#section-5.1.
Actually, an OpenURL requires a program and a database to resolve it.
It doesn't link directly to the resource. In fact, that's the point of
the OpenURL: it goes through a resolver database in order to provide
the "best" source for the resource to the user.
This is why I have thought that OpenURL demonstrates the power of
consistent, >standardized metadata:
In fact, OpenURL data is far from consistent, as folks who have had to
program the logic in OpenURL resolvers can attest. But you are right
in that OpenURL does allow you to convey standardized data, if you've
got it, from one system to another.
Concerning linked data, it is simply the way the World Wide Web
works, plus there is the assumption that the more links a resource
has both to it and from it, the greater use it has for everyone. I
am sure that almost any page > you see on the web is composed of
dozens of separate files brought together from all kinds of places:
The difference between linked data and web pages is that web pages are
made up of documents or resources of various kinds: html text, image
files, sound files. The point of linked data is to allow you to put
actual DATA on the web. This includes scientific data (human genome),
statistics and numerical data (census), geographic data, bibliographic
data. It's like using the web as your database management system, and
having everyone's data in the same system and available for use.
http://linkeddata.org/ is a good way to view this. Click on the graphic.
But all of this is being done now in dbpedia. Look at http://dbpedia.org
/page/Benjamin_Spock, scroll to the bottom and you can see the
record in different types of RDF.
Yes. DBPedia is the "center" today of the linked data cloud, and yes,
there is a lot of work that has already been done, especially in the
creation of basic data standards (kind of like the basic standards of
the Internet, TCP/IP and all that). Where we are, though, is that we
are missing the tools we need to make the data friendlier than
dbpedia. We do not have, for example, tools that would take a bunch
of library linked data [1] and make a nice catalog out of it. Or that
would allow users to create their own applications out of the data. So
we've got standards for how to create the data, we've got data, but
we're at the 'WWW 1990' point: all the underlying technology, but no
browser, no Mosaic. When that happens, some very interesting things
will be possible, but I don't know what they are at this point, just
as we didn't really know what the web would look like before we got
our hands on Mosaic.
This is one of the reasons why I think switching to MARXML would be
one single >step in the right direction, and also why we should
really consider working >with dbpedia: a lot of the technical work
has been done already.
No, MARCXML does not move us toward dbpedia. At least, not the MARCXML
that is the LC standard. That is, as Jonathan has pointed out, just a
different format of the same old MARC record with all of the same
constraints. Also, linked data and XML are VERY different approaches
to data modeling, and many feel that XML actually gets in the way. The
direction that I am trying out (and not sure yet how it will all work
out) is to break MARC up into its logical component parts -- it's
actual data elements. You can follow this as I develop it at:
http://futurelib.pbworks.com/w/page/29114548/MARC-elements
kc
[1] Bibliographic data in SemWeb format is beginning to be listed
here, but there really isn't a central clearing house:
http://ckan.net/group/lld
--
Karen Coyle
kco...@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
