On Wed, 1 Mar 2000, Renato Iannella wrote:
>
>
> --On 1/3/00 10:34 AM +0800 Simon Cox wrote:
>
> > I disagree.
> >
> > Structured datatypes exist through "schemes", they always have.
> > This is a very effective, scalable, modular place to put them.
> > In general it is also very safe.
>
> I disagree ;-)
I, obviously, agree :-) with Ren
> Such data, that is a value conforming to an Encoding Scheme (eg URI)
> should be considered an "atomic" value. No *further* *interoperability*
> is *assumed* for this value (although you could).
Actually, I was very surprised that we had to vote on different "schemes"
in the Hungarian Ballot. Remove most of them, if not all, those and leave
them for the different communities to implementors... I still thing that
DC need its own DCT1 (the types by Rebecca et al.) and a DCT2, but all
the different classification systems and controlled vocabularies (DDC,
UDC, LCSH) are so obvious that there is no need to vote on them.
> This means we are happy for interoperability at the "URI level" (since
> we use a Scheme) but we would not break that up into Protocol, Host,
> Port, Directory, FileName elements (the structure) because it does not
> give us much more in terms of interoperability.
>
> However, what we are saying is that there are some qualifiers
> (that represent stucture for an Element) that we believe should
> be represented as structured elements (eg the CCP qualifiers)
> since Name, Role etc are seen as good *interoperability* access
> points.
>
> The way forward for us is to allow for a Structured Qualifier
> Principle then vote on all the proposals.
>
> Cheers...Renato <http://purl.net/net/renato>
> Principal Research Scientist, DSTC <http://www.dstc.edu.au>
>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|