I said:
> > I'm trying to resist using the term "application profile" here to
> > describe objects in this second class,
Rachel said:
> I too will resist! I see the DCMI as a 'standards
> making body' whereas I see application profiles as emerging
> from elsewhere, from implementors adapting and localising
> 'standards'. I realise its often the same people involved in
> both activities but I think its overloading the concept if
> DCMI use it as means to define their vocabularies..
I must admit that conceptually I see no difference between what I called
a "usage" (e.g. "simple DC" or "qualified DC" as defined in [1]) and a
non-DCMI "application profile" like, say, AGLS, or an application
profile coming out of a DCMI interest/working group like the DC-Library
AP.
I think I see the point you are making, but it seems to me the only
distinction between what I called a "usage" and an "application profile"
is one based on the source of the object/construct.
Looking at [2], I can see that this "political" dimension is embedded in
the definition of "application profile" used there
> schemas which consist of data elements drawn from one or more
namespaces, combined
> together by implementors, and optimised for a particular local
application
Actually I don't think I had fully registered the presence of "by
implementors" until I looked at this just now! I guess I'm arguing for a
more "functional" view: it's the "drawing", "combining" and "optimising"
which are the significant considerations, rather than whether that
drawing/combining/optimising is being done by a standards body or an
implementor.
Anyway, returning to the point about "Simple DC", I think your initial
message suggested that you might use the term to mean something
different from what [1] calls "Simple DC", but now I'm not so sure?!
Cheers
Pete
[1] http://www.ukoln.ac.uk/metadata/dcmi/dc-xml-guidelines/
[2] http://www.ariadne.ac.uk/issue25/app-profiles/
|