This is *great*, Ross.
I've finally made it through this thread after a bit of time away from
the office, and wanted to chime in on the notion of minting URIs now,
and hanging more and more data off of them as time goes on.
I'm surprised no one pointed out that VIAF did exactly that a little
over a month ago. [1] At the moment, the viaf server seems to be down,
and even if it was up, you'd see that the RDF representation is a very
bare-bones FOAF description, but the URI is invaluable in and of itself.
Imagine the value once the various language and script representations,
as well as all the ancillary data in the various authority files, can be
included?
As some of you have heard me say, I think the library world needs to
take the lead on a SKOS-like set of properties for name authority data,
and I know the FOAF folks are interested in being involved as well.
Here's an opportunity to really try to do just that, though given the
state of FRSAD and FRAD, I'm not sure we have much of a model to work
with...
Ross - in the spirit of "Any and all recommendations welcome", how hard
do you think it would be to hook these URIs into your quick proof of
concept?
Best,
-Corey
[1]http://outgoing.typepad.com/outgoing/2009/09/viaf-as-linked-data.html
Ross Singer wrote:
> On Sun, Nov 1, 2009 at 2:34 PM, Karen Coyle <lists_at_kcoyle.net> wrote:
>> Great examples, Ross!
>
> Thanks, but, obviously, it's really, really, really, really rough.
>> I do think you have a mix here of Work and Manifestation (because of the
>> LCCN and ISBN and the links to manifestations), but I wonder if we won't be
>> resolving that with class and domain definitions... So that the subjects
>> will be defined as Work, and then you've connected that Work to
>> Manifestations by including those manifestation-related identifiers?
>
> Yes, well, you've touched on a good point here. There is sort of an
> assumption here that these are /mostly/ Manifestations. I've largely
> avoided explicit FRBR assertions 1) because there is no persistence
> layer to this app and there is no obvious way to "proxy" works or
> expressions from the LCCN Permalinks service 2) I need to see more
> examples of records to know if there's even consistency in determining
> if they are manifestations or not.
>
> So, right -- this is largely a pragmatic approach trying to use what's
> actually available in our current data set. And, of course, it's a
> work in progress.
>
> That being said, there's at least a nod to FRBR WEMI in there, rather
> than saying http://lccn.heroku.com/94510751 is the same thing as
> http://dbpedia.org/resource/The_Hobbit_films (which, now that I'm
> looking at it, is the wrong resource anyway -- it should be
> http://dbpedia.org/resource/The_Hobbit_%281977_film%29 -- might need
> to use Freebase for films) - it's using dcterms:isVersionOf to help
> explain that we're actually referring to a videocassette of the movie,
> not the movie as a Platonic ideal.
>
> On the flip side, the Work-level assertions (subjects, in the Nirvana
> case, the track listings) are included because I have nowhere else to
> put them presently (the only option would be to model the work and
> expression in a blank node, but I don't see that buying much). This
> is definitely an area that needs more energy invested in it.
>> As an FYI, whereas you have included both display forms and URI forms of
>> subjects separately as:
>>
>> <dc:subject>Soldiers--Fiction</dc:subject>
>> <dc:subject>Teenage girls--Fiction</dc:subject>
>> <dc:subject>Teenage pregnancy--Fiction</dc:subject>
>> <terms:subject
>> rdf:resource="http://id.loc.gov/authorities/sh2007101961#concept"/>
>> <terms:subject
>> rdf:resource="http://id.loc.gov/authorities/sh2008104232#concept"/>
>> <terms:subject
>> rdf:resource="http://id.loc.gov/authorities/sh2008108377#concept"/>
>>
>> Andy Powell recently put up examples on his blog in this format:
>>
>> �<dcterms:subject>
>> � � �<rdf:Description
>> rdf:about="http://id.loc.gov/authorities/sh85101653#concept">
>> � � � �<rdf:value>Physics</rdf:value>
>> � � �</rdf:Description>
>> � �</dcterms:subject>
>>
>> Which treats the display form as a label on the URI value form. It has the
>> advantage of keeping the two together as a unit, but I'm a bit uneasy about
>> the inclusion of a single display form, unless you really know what audience
>> you will be showing it to (e.g. this excludes carrying alternate entry
>> vocabulary). And I'm still unclear what the explicit relationship is between
>> the rdf:Description and the rdf:value... but in any case, this seems to be
>> the DCMI form.
>
> Right, I could probably add that (and could alleviate the duplication
> between dce and dcterms).
>> I also wonder what we'll do with situations where we have:
>>
>> � � � �Teenage girls -- Fiction -- Comic books, strips, etc.
>>
>> and id.loc.gov has only
>>
>> � � � �Teenage girls -- Fiction
>>
>> It seems that (other than the problem of matching a longer string to a
>> shorter, rather than vice-versa) we'll want a way to say: this subject
>> heading is an extension of this LC subject in the LC authority file. It
>> seems like it could be a simple relationship... yes?
>
> Hmm... "probably". Perhaps (the non-existent)
> <http://lccn.heroku.com/subjects/Teenage girls -- Fiction -- Comic
> books, strips, etc> <skos:broaderTransitive
> <http://id.loc.gov/authorities/sh2008112612> ? That could possibly be
> the way to bridge subjects /based/ on authorities to authorities,
> yeah?
>
> Thanks for the feedback - it really helps.
>
> -Ross.
--
Corey A Harper
Metadata Services Librarian
New York University Libraries
20 Cooper Square, 3rd Floor
New York, NY 10003-7112
212.998.2479
corey.harper_at_nyu.edu
Received on Wed Nov 04 2009 - 19:39:49 EST