Mikael Nilsson wrote:
> 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).
>
I believe that's what I was trying to do. Could you give a code example
that we could use on the "patterns" page? Thanks.
> 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.
>
Most of the lists we work with today do not have URIs for values. That
would be a different case.
Thanks,
kc
> /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
>>>> ------------------------------------
>>>>
>>>>
>>>>
--
-----------------------------------
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
------------------------------------
|