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.
Received on Mon Nov 02 2009 - 10:13:47 EST