 |
 |
On Fri, 10 Oct 2003, Mikael Nilsson wrote: > An additional comment to my previous mail: > > On Thu, 2003-10-09 at 22:57, Mikael Nilsson wrote: > > Looks good, eh? Is e) how we want to represent element encodings? For > > all properties or only for some? Or is using the RDF datatype construct > > just something outside the scope of DC, and we should stay with b)? > > Is it even the case that DC has implicitly defined two kinds of element > encodings? > > First, the "element value type" that tells you what *kind* of value you > have. It is a MeSH or a LOC entry, or what is it? > > Second, the "element value encoding" that tells you how the string value > is to be parsed. > I'm starting to think that maybe DC has again been unclear about the > nature/semantics of the "element encodings". We do have (i) element refinements (AKA qualifiers). They are making an element's semantics more specific. We also have (ii) Value encoding schemes. Element encodings are unknown to me, but I might have missed something. The distinction between these two concepts are not entirely clear in theory, but in practice this seldom poses any problem. For example, subject can be refined to classification (an element refinement) and its value encoding could be Library of Congress Classification (LCC). However, it is common practice (or used to be) to say that we have a value encoding LCC to subject -- which obviosly means that the subject in question is actually a classification, we just didn't think that was strictly necessary to convey that info. We all knew that LCC is a classification, don't we ;) Sigge > Something for the abstract model to sort out :-) > > /Mikael > -- > Plus ça change, plus c'est la même chose >