Pete wrote
> Hi Rachel,
>
>
> I think you may be right. There's a sort of nesting/recursion going on
> and it needs to be better expressed.

Certainly.

>
> > 2. relationship between record and description

> >
> > I am a little uncomfortable about use of term 'record' to
> > characterise set
> > of descriptions, given that description can be record, and set of
> > descriptions can be record. Isn't that a bit confusing?
>
> I don't think the model says a description can _be_ a record (or if it
> does, it shouldn't). It says there might be only one description in a
> record. They are still different types of entity/resource. Just because
> your packet contains only one Hob Nob, that doesn't make that Hob Nob
> the same thing as the packet. I hope. ;-)

Hmmm, so what makes a record?
Maybe "record" is an unnecessary term the paper uses.


>
> Sometimes I do wonder whether "record" belongs in the model or not...  I
> think Andy's initial draft excluded it (or used record where now we use
> description) but then we had a discussion here about whether the fact
> that descriptions/statements are provided as a specific set is
> significant, and that information should be preserved when
> descriptions/statements from different sources are all merged. And I
> thought we decided it was significant
>
> http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0309&L=dc-architecture&T=
> 0&F=&S=&P=2061
>
> http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0309&L=dc-architecture&T=
> 0&F=&S=&P=2159
>
> > I would want to distinguish 'record' with description and a couple of
> > administrative elements (date of record creation, record id)
> > from 'record' that tried to describe artist, painting, gallery etc

These so-called "admin" meta elements are just metadata for a resource
called "record".



>
> > Is there any possibility of using 'description-set' or some other
> > collective term to characterise the latter?
>
> I'd be happy enough to change the name of the class from "record" to
> something else.

It's not the problem to change the name. The issue is to provide a
definition of "record".



> > 3. Application profiles (APs)
> >
> > It seems to me that section 5 elides from
> > application profile to record ... missing out something, and
> > I must admit I'm not sure what.
>
> Perhaps the "missing link" between "application profile" and "record"
> lies in the fact that "a metadata application" probably requires the
> description of more than one type of resource (artists, paintings, and
> galleries, not just artists). So if an application is "a declaration
> specifying, at a minimum, which properties are used within a particular
> metadata application", then it typically specifies the properties used
> (and how those properties are used) in the descriptions of resources of
> several different types, not just descriptions of resources of a single
> type - and those description suse diffeent sets of properties in
> different ways. I might want to say that the use of the property
> dc:creator is mandatory for the description of a painting, but not
> permitted for the description of a gallery, but I want to provide that
> information in one AP.
>
> I'm comfortable with this notion that a DCAP might describe the use of
> properties in multiple descriptions. But I think that the description of
> a DCAP as
>
> > a declaration specifying, at a minimum, which properties are used
> within a particular metadata application.
>
> is perhaps too loose - or at least we need to specify more clearly what
> we mean by "metadata application". I can conceive of a "metadata
> application" reading records containing metadata descriptions from lots
> of external different sources, where each source provides records
> containing descriptions of resources of different types.

Maybe you're talking about OWL like restriction classes, but i'm not sure
about that.


>
> So e.g. my application is merging
>
> - source 1: records containing descriptions of collections, locations,
> location-administrators, and administrative metadata about each of these
> descriptions;
> - source 2: records containing descriptions of artists, paintings, and
> administrative metadata about each of these descriptions;
> - source 3: records containing descriptions of cities and public
> transport companies, and administrative metadata about each of these
> descriptions
>
> Now you could have an "application profile" that covered the description
> of properties used in the whole of that "metadata application" (and the
> current definition seems to suggest that would be the case); but it seem
> to me to be useful (in allowing data providers to disclose descriptions
> of their data and service providers to discover descriptions of that
> data), there would be three application profiles, each describing the
> properties used in descriptions in records from each of those sources.

Just to describe properties somewhere used by an application seems
insufficient to me.

Maybe an "application profile" is an ontology, which primarily defines
(a) class(es)?

One problem seems to be that the specifics of RDF(S), OWL (flavours)
and XML Schema languages/XML DTD's/ (X)HTML restrictions
are not clear enough addressed in the paper.


> > I am fine about the definition of an AP. It is stated that an AP is a
> > declaration of properties used etc, which is fine, and fits
> > with view that the declaration can be thought of as a schema.

As i said before, just properties do not suffice in my view.

> >
> > However compliance with an AP (a schema) is a different
> > issue, and to go
> > on to say that any individual records on a per record basis can be
> > classified as Simple or Qualified according to whether it
> > does or does not
> > comply to a number of constraints is surely missing something?
> > over-simplifying?
> >
> > In that I may have application that uses Qualified DC
> > application profile
> > declaration, but many instances of records in that
> > application might be simple DC records?

There is quite a lot of mixture of notions around.


>
> And if tomorrow I create another profile "My-AP" that expresses the same
> constraints as "Simple DC" but also says uses of dc:identifier, dc:title
> and dc:description are mandated, then my set of "My-AP" records also
> meets the requirements for "Simple DC" and "Qualified DC".


There is a dumbdown to those.

>
> That all seems fine to me.
>
> > Maybe all I am saying is that a description needs to signify
> > which AP it
> > is compliant with, otherwise you cannot judge which of many APs it
> > complies with?
>
> But you can never know this just from the description/record, I don't
> think?

hmmm....Maybe some metadata authors want to express the compliance.

>
> Taking the example above, tomorrow all "My-AP" records are also "Simple
> DC" and "Qualified DC" records. The day after tomorrow you create
> "Your-AP" that requires the use of dc:identifier and dc:title, but
> leaves dc:desciption optional. So then all my "My-AP" records also
> conform to "Your-AP".

Think this is missing a point: Why one should formulate something
called "application profile" when it is irrelevant?

>
> At the moment (it seems to me) the only way you can test whether this is
> the case is by checking each record against "Your-AP". In theory at
> least, if we can develop ways of expressing these AP constraints in
> machine-readable form  - which first means agreeing what an AP is, which
> I still don't feel we have managed to do - , then (I think?) we could
> develop an application that read your description of "Your-AP" and my
> description of "My-AP" and worked out - from those "schemas" alone -
> whether the constraints were such that any record conformimg to "My-AP"
> would also conform to "Your-AP". (Which I think is the sort of thing we
> are being asked for In Another Place.)
>
> > 4. Dumb-down of records
> >
> > Section 6 talks about dumbing down records... should this be
> > dumbing down
> > descriptions?  in that a record according to model might
> > contain more tha
> > one description, so dumbing down would not result in Simple DC record
> > (which by definition contains only one description)?
>
> Urgh, not sure! ;-) Probably.

Seems the notion of a simple record as opposed to a simple description
is not very useful.

>
> > 5. Terminology section 8
>
> I think this is fine as it is. The notion of a "top-term" is not
> important to the model, which is defined in terms of "properties".

Elements don't need to be "top-terms". They are the punch line for DC dumb-down.
The also come up in the notion of DC "simple".
They must play a role in a DC-model.


rs