I have not been following this whole thread, but I will report that the Library of Congress, which is the maintenance agency for ISO 639-2, will be making that standard available as RDF/XML in the future (using SKOS). Thus of course we will be providing URIs for entities which are languages and using altLabels in SKOS to specify the alternative codes. (If you're not familiar with it, ISO 639-2 has 20 languages that have alternative codes for historical reasons, called the bibliographic and terminology codes, but these are too be considered synonyms to represent the same language, e.g. "fra" and "fre" for French.) There will also be relationships asserted to the other language code lists (639-1, 639-3 and 639-5).
It will be under http://id.loc.gov and hopefully available by November or so.
Rebecca
----------------------------------------------------------------------
Date: Tue, 21 Jul 2009 18:05:48 -0700
From: Karen Coyle <[log in to unmask]>
Subject: Re: More on lists
Once again, Pete, thanks so much for your reply. A few lingering
questions, below ;-)
>
> OK, the language example is slightly different, at least if using DCMI's
> own terms, because DCMI has modelled ISO639-2 as a syntax encoding
> scheme, rather than a vocabulary encoding scheme - a set of "strings",
> rather than a set of "things", if you like.
>
If a VES is a set of unstructured strings, then I must say that there
will be few of them in libraryland. There's often some structure, either
to the entries or between them ("see:" "use for" "broader"). In the
cases where there isn't any structure, there probably should be to make
the list more usable. :-)
> If I want to specify that my statements using the dcterms:language
> property should use only one of those three codes, "eng", "fra", "spa",
> rather than any of the codes in the list, then I could use a template
> like:
>
> <StatementTemplate type="nonliteral">
> <Property>http://purl.org/dc/terms/language</Property>
> <NonLiteralConstraint>
> <ValueStringConstraint minOccurs="1" maxOccurs="1">
> <LiteralOption>eng</LiteralOption>
> <LiteralOption>fra</LiteralOption>
> <LiteralOption>spa</LiteralOption>
>
> <SyntaxEncodingSchemeOccurrence>mandatory</SyntaxEncodingSchemeOccurrenc
> e>
>
> <SyntaxEncodingScheme>http://purl.org/dc/terms/ISO639-2</SyntaxEncodingS
> cheme>
> </ValueStringConstraint>
> </NonLiteralConstraint>
> </StatementTemplate>
>
OK, if I understand this, you restrict the values to the ones you want,
then tie the statement to the SES. How does one know that's an "AND" not
an "OR"? e.g. "eng" "fra" "spa" OR ISO639-2. Putting it another way, if
I list more than one VES or SES, does that mean I could use either one?
If not, I probably can't use either because I can't satisfy both with a
single property value.
> An alternative approach might be to model ISO639-2 as a set of things
> (languages), in which case, it is similar to my colour scheme example,
> and the approach I used in the previous message would apply in more or
> less the same way i.e. I could use a tempalte like
>
> <StatementTemplate type="nonliteral">
> <Property>http://purl.org/dc/terms/language</Property>
> <NonLiteralConstraint>
>
> <VocabularyEncodingSchemeOccurrence>mandatory</VocabularyEncodingSchemeO
> ccurrence>
>
> <VocabularyEncodingSchemeURI>http://example.org/my/ISO639-2</VocabularyE
> ncodingSchemeURI>
> <ValueStringConstraint minOccurs="1" maxOccurs="1">
> <LiteralOption>eng</LiteralOption>
> <LiteralOption>fra</LiteralOption>
> <LiteralOption>spa</LiteralOption>
> </ValueStringConstraint>
> </NonLiteralConstraint>
> </StatementTemplate>
>
>
This looks very close to what I was modeling, and makes more sense to me
because the selection of strings is within the VES URI tag. In this case
it seems pretty clear that the strings must be part of the VES. Well, at
least I can imagine interpreting it that way.
> There's no guarantee/requirement that the document I obtain about the
> VES would also include information about the individual members of the
> VES. It might do, but it might not: it's really up to the URI owner how
> they parcel up the information they provide, I think, and the size if
> the vocabulary might be a factor in that decision, I think.
>
Right. That's true for all of the URIs, but I'm assuming that someone
developing the metadata and the application has knowledge of the various
vocabularies that will be used, what their structure is, and what they
can provide in response to a query.
> scenario is handled, but in the case where the individual members don't
> have URIs, then I guess descriptions of all those members could be
> served in a single document available by dereferencing the VES URI -
> though depending on the size of the set, that may be a large chunk of
> data.
>
I suspect we'll be fudging this one for a while... making "deals" with
vocabulary providers about what we can and cannot get from them. I'm
also of the mind that we won't be dereferencing on the fly but will be
caching vocabularies in a way convenient to our application, with maybe
a community commitment to schedule updates and refreshing of
vocabularies on some schedule to keep us all more or less in sync. In
other words, it's going to be something of a manual process for the
foreseeable future, but it'll still be better than what we do today.
kc
--
-----------------------------------
Karen Coyle / Digital Library Consultant
[log in to unmask] http://www.kcoyle.net
ph.: 510-540-7596 skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
------------------------------
End of DC-ARCHITECTURE Digest - 21 Jul 2009 to 22 Jul 2009 (#2009-39)
*********************************************************************
Rebecca S. Guenther
Senior Networking and Standards Specialist
Network Development and MARC Standards Office
Library of Congress
101 Independence Ave. SE
Washington, DC 20540-4402
(202) 707-5092 (voice)
(202) 707-0115 (FAX)
[log in to unmask]
|
