[NGC4LIB] FRBR WEMI and identifiers

Ross Singer wrote:

On Tue, Nov 17, 2009 at 4:30 AM, Weinheimer Jim wrote:

> See an earlier message where I mention that the pre-coordinated LCSH strings don’t work at all well in an online environment. This is no surprise since they were designed for a completely different technology. I think you can have them work well, but in order for this to happen today, the “strings” must become more flexible, but as I discovered, RDF does not allow the kind of flexibility to do what I mention in this message. Therefore, we either give up on LCSH or seek new solutions.
> https://listserv.nd.edu/cgi-bin/wa?A2=NGC4LIB;QfWMyg;20091104085554%2B0100
So are you purposefully ignoring the half dozen-plus counter arguments to your erroneous claim?

Not at all, but please point out to me how I can take “Communication–Political aspects–United States” using the power of the semantics contained withing the 650 field:
650 $aCommunication$xPolitical aspects$zUnited States (topical subject – topical subdivision – geographical subdivision)
to get a more flexible display of the type I pointed out:
topical subdivision – geographical subdivision – topical subject
Political aspects United States Communication,
using the RDF from

It was my understanding from everything in this thread that this cannot be done using RDF and then Karen pointed out that the problem is with SKOS. That’s fine, but the final result is the same: that what we have in id.loc.gov is totally inflexible. That’s why I said that other technologies may be needed to do these sorts of things. I understand very clearly that the purpose of the RDF files from the id.loc.gov site are supposed to be there only for referencing, but I also tried to point out that this is not nearly enough to get a web designer to use it in reality. The web designer must see added-value, and on the web, this means links above all else. Can you say why somebody would use id.loc.gov and not dbpedia? And even if we placed our links into the relevant URIs in dbpedia, there would still be no added value since there would still be no links.

As I stated before, I am not an expert in these matters, but I still don’t see how you can get flexible displays from the RDF that I see. If there is a transformation involved, e.g. breaking everything at the hyphens, there are still no semantics of the subdivisions, which are critical.

If I am wrong, please enlighten me, I would love to be wrong on this and learn that perhaps the LCSH may be of real use to everyone, but please focus on what is possible today, now, with the tools and data we have at hand, not what might be done after 10 years and the willing cooperation of half of the people on the internet, because there may be many other solutions available in 10 years, and I don’t know how much cooperation we’ll get. People have been waiting for a long time already to see something cool emerge from libraries and almost nothing has happened.

I think we can all agree that LCSH as subject strings are not useful for the general public today. My own opinion, although I may be wrong, is that LCSH should be useful and potentially they can be useful so long as–as I wrote–we link what can be linked, and what I see at id.loc.gov does not allow that. Still, above all else LCSH needs to be flexible, otherwise, we are stuck with pre-20th century browse displays from a card of printed catalog. Does id.loc.gov allow these possibilities? Or do we need a different technology?

Jim Weinheimer