Bo, I've just added lexvo links. Thanks for that.

great to see this happening. Some comments from my end:

I would favor the use of dcam:memberOf even for dereferenceable URIs, because 1. it makes processing and sorting out mappings much easier without having to rely on an external data store every time and 2. I don't see dcam:memberOf used much in external data sets. So even if a user agent would follow its nose, it is doubtful that by inspecting a single concept it could reliably determine which vocabulary it is part of.

Nothing in http://id.loc.gov/authorities/sh95000541.rdf tells you that this is an LCSH (except for the skos:inScheme assertion which I find a little ambiguous if LC wants to publish more than just LCSH at this URI).

In the end it might come down to whether you find it useful to follow Dublin Core conventions. It might even be useful to state the preferred heading or caption of the subject identifier. I think there are at least two ways to do this.

You could basically reiterate a couple of triples found at the other end (which might be problematic because those have to be kept in sync with the original data source) or use DCAM conventions to indicate that you are not really making assertions about a concept that is not your own. Rather, you are just giving additional information that are relevant in your context but may be disregarded when graphs are merged. So basically:

World Wide Web

versus

World Wide Web

I don't know which one is better (if any). The rdf:value approach could make processing easier because rdf:value is typically used for identifying the main value of several values. This scenario seems to be a prime use case for that: “What is the value of dcterms:subject?”

Re other data sets to link to: We now have dewey.info, ;-) so perhaps it might make sense for you to consider using Dewey URIs in your data? The data currently available there aligns mostly with what you already have in the first subject assertion. It could be rendered like this:

Constitutional & administrative law
Derecho constitucional y administrativo
Droit constitutionnel et administratif
…

Or the rdf:values could omitted altogether to spare the pain of synching and updating …

Regarding your wish to hear of other vocabularies to link to, Lingvoj rdf file currently describes 522 languages. The Library of Congress – UNESCO World Digital Library project will potentially have many more human language descriptors for content. Currently UNESCO lists 193 member states (and 6 associate members) that have cultural content in many living and extinct languages. The current Ethnologue database lists 7,357 distinct language identifiers. Of these, 421 represent extinct languages, 396 are nearly extinct, 29 are a second language only, and the remainder are listed with "living" status.

Lexvo.org rdf file (lexvo_2008-12-27.rdf) currently describes more than 7000 languages in the form http://www.lexvo.org/id/iso639-3/eng

Re: having more examples up on the DCMI Web site, the pattern Karen referred to (and others like it) is listed in

http://dublincore.org/documents/dc-rdf/

That document uses the terminology/concepts of the DCMI Abstract Model (e.g. "Vocabulary Encoding Scheme"), but since DCMI uses that categorisation in its list of terms in

http://dublincore.org/documents/dcmi-terms/

then hopefully it is enough to give an indication of their intended use.

I tend to agree with your suggestion that, where a URI for the concept is used, and that URI is dereferenceable to more information about the concept, and in a "linked data" context, it may be debatable how much value there is in including the dcam:memberOf triple, but I guess it may be helpful to some applications to have that information included in the "instance".

Re DCMI documentation more generally, yes, I'm afraid a good deal of the documentation on the DCMI Web site is somewhat out-dated and sorely in need of a substantial overhaul [err, personal opinion only, I hasten to add!]

So I guess there are just some missing headings, and missing links?

Still, this sort of linked hierarchy is potentially much more useful for OL users.

The other thing about LCSH URIs is that they do not represent complete subject headings. LCSH authority data is a kind of pattern dictionary for the creation of actual subject headings. So while there is an authority entry for:
African Fiction (French)
the subject headings in books are:
African Fiction (French) — 20th century
African Fiction (French) — 20th century — History and criticism
etc.

Each of these would be assigned the same LCSH URI, but they are not the same subject heading, and there is no URI for the heading in the bibliographic record. I'm not quite sure how to represent this "based on" relationship that exists between the subject heading and the LCSH entry. It is a particular property that we need to carefully define.

I'd love to see more examples like this up on the DC website itself, too. Or maybe they're already there and I just couldn't find them.

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dcterms="http://purl.org/dc/terms/"
         xmlns:dcam="http://purl.org/dc/dcam/">
 <rdf:Description rdf:about="http://example.org/book/123">
  <dcterms:subject>
    <rdf:Description>
      <dcam:memberOf rdf:resource="http://purl.org/dc/terms/LCC"/>
      <rdf:value>HV3709</rdf:value>
    </rdf:Description>
  </dcterms:subject>
 </rdf:Description>
</rdf:RDF>

I have used it this way for the RDF export from the Open Library (openlibrary.org). Soon to be blogged at http://blog.openlibrary.org

<dcterms:subject rdf:resource="http://id.loc.gov/authorities/label/Women"/>
<dcterms:subject rdf:resource="http://purl.org/NET/decimalised#391"/>
<dcterms:subject rdf:resource="http://dbpedia.org/resource/Women"/>

And folks can follow their noses in the linked data fashion to discover that a subject is LCSH or DDC. I guess an alternative would be to include dcam:memberOf pointing at dcterms:{LCSH,DDC} within dcterms:subject, but it's not clear to me if that's helpful or what it'd do to the resulting RDF, e.g., would it create blank nodes (a linked data no-no, I apparently).

As for how I'm doing the linking, it's very crude. I went through the various elements within the WDL domain model and thought about how appropriate it'd be for each to point at a URI rather than a literal. For those where it's appropriate — for instance, a date range or an extent/physicalDescription might not be appropriate in contrast to institution names, geographic terms, and subject headings, or even titles — the code cleans up the string in question and probes at potential URIs in a small number of vocabularies. If the URI exists, returns a 200 HTTP status code, and returns an RDF graph, I use the constructed URI.

It's pretty crude, like I mentioned, and there are obvious inefficiencies and faulty assumptions here. Baby steps.