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".
Sorry, didn't read this until I'd sent my first response. Yes, we already
differentiate these two things... as 'synatx encoding scheme' and
'vocabulary encoding scheme' - but see previous message for reasons why I
think that even syntax encoding schemes may actually be saying something
about the class of the value resource.
Andy
--
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell +44 1225 383933
Resource Discovery Network http://www.rdn.ac.uk/
|