I responded only to the issue of dc-ds-xml, which I believe has more or
less nothing to do with your question regarding APs....
What you're asking for is a way to limit the set of allowed values
within a given VES. What you can do using the current DSP model is to
express BOTH a (mandatory) VES URI constraint AND a list of literals.
This gives you a set of values (which must then logically be a subset of
the VES).
This does NOT give you the option of specifying, for each allowed value,
several literals (both the code and the label). That would require a
dependence relation between two value string within the same non-literal
value, and such dependence relations are generally not expressible using
the DSP model.
The preferred way in RDF land would likely be to just give a list of
allowed value URIs together with the VES URI constraint. This way, the
URI could be used to lookup codes, labels, relations, etc using a linked
data approach.
/Mikael
lör 2009-07-18 klockan 10:13 -0700 skrev Karen Coyle:
> The idea here is that there are folks who want to use standard
> vocabularies, but they don't want to use the ENTIRE vocabulary, only a
> selection. Language is a good example, because the ISO language list is
> huge and you may not want to allow all those values in your metadata. So
> you make a selection and want to validate that you are using only the
> values in your selection.
>
> You could create your own list and not refer to the standard list, but
> I'm thinking of a case where the standard list may have additional
> information (code + display form, definitions, see references etc.).
> Plus, there is always an advantage to using the standard list because it
> may change and you want to be in sync with those changes.
>
> So, how could this be done in your application profile? Or would you
> have to do this in your application, not the application profile?
>
> kc
>
> Mikael Nilsson wrote:
> > tor 2009-07-02 klockan 11:11 -0700 skrev Karen Coyle:
> >
> >> The following example shows a /description/ in which the third
> >> /statement/ includes a /non-literal value surrogate/ containing two
> >> /value strings/:
> >>
> >> [excerpt from example:]
> >>
> >> <dcds:statement dcds:propertyURI="http://purl.org/dc/terms/subject"
> >> dcds:vesURI="http://purl.org/dc/terms/LCSH">
> >> <!-- non-literal value surrogate - multiple value strings -->
> >> *<dcds:valueString>Metadata</dcds:valueString>*
> >> *<dcds:valueString>Métadonnées</dcds:valueString>*
> >> </dcds:statement>
> >>
> >>
> >> Because this is XML and not XSD (or some other language that includes
> >> constraints) it isn't clear to me what the meaning is to having both a
> >> vesURI (as it is called here) and some value strings. I don't see a
> >> reason to include specific values unless the intention is to limit the
> >> selection to those values, but perhaps I am missing something...
> >>
> >
> > Karen, it seems to me (?) you're missing that this is instance data. In
> > instance data there is no notion of "selection". Only gving a VES would
> > not actually give you a useful value.
> >
> > The reason there are several values is in this case simply to give
> > several translations, for the benefit of the consumer (who could just as
> > well, but not as easily giver the lack of a value URI, lock up the
> > translation in an LCSH document somewhere).
> >
> > Or did you mean something else completely?
> >
> > /Mikael
> >
> >
> >
> >
> >> kc
> >>
> >>
> >> Karen Coyle wrote:
> >>
> >>> I know I may seem obsessed with lists, but the fact is that the
> >>> library world relies heavily on controlled lists of values and these
> >>> will make up a large part of records used by libraries. I'm also
> >>> struggling with the controlled "lists" which are more than simple
> >>> values -- those that have structure or additional data. I'd like to be
> >>> able to define all of these so that we can be clear when we are
> >>> discussing them. Sometimes the current terminology and common view
> >>> gets in our way.
> >>>
> >>> 1) external lists -- these are lists that are external to the
> >>> application profile, maintained elsewhere. They may be simple lists,
> >>> or they may be data structures such as name authority records. What
> >>> the application profile will incorporate will be an identifier for the
> >>> list, but it seems to me that the AP itself may not have any
> >>> "knowledge" of the nature of what it points to nor of how the
> >>> application gains access to the list values.
> >>>
> >>> 2) internal lists -- when the values in the list are included in the
> >>> AP definition. These values are probably going to be literals,
> >>> although they may be structured (e.g. a code and a display value). I
> >>> suppose they could have URIs, but that seems both unlikely and
> >>> unnecessary. If you think anyone else will want to share them, then
> >>> you should move them out of the AP into a neutral space or registry.
> >>>
> >>> I now have a third possible category...
> >>>
> >>> 3) external lists, with a selection of values -- this is a situation
> >>> where one refers to an external list (e.g. iso 639-2), but the AP
> >>> selects a subset of the values as valid for the application ("en" "fr"
> >>> "sp"). The values may be simple strings, structured strings, or URIs,
> >>> and how the application should work with them should be based on the
> >>> referred to list, not the AP statement.
> >>>
> >>> Now here's a question: what if the external list is NOT just simple
> >>> values and you want to refer to a part of the structure of those
> >>> values? For example, with the ISO languages, the standard list has
> >>> codes and spelled out forms of the language. How could you indicate
> >>> that you want to use just the code, or just the spelled out form, or
> >>> both? The library name authority records have numerous fields and
> >>> subfields. What if you only want to select personal name fields (100
> >>> tag) and only certain subfields from that field? Can these be defined
> >>> in the AP, and if so, how? Or is this best left for the application
> >>> itself?
> >>>
> >>> 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
> >> ------------------------------------
> >>
> >>
>
--
<[log in to unmask]>
Varning! E-post till och från Sverige, eller som passerar servrar i
Sverige, avlyssnas av Försvarets Radioanstalt, FRA.
WARNING! E-mail to and from Sweden, or via servers in Sweden, is
monitored by the National Defence Radio Establishment.
|