Hi Douglas,

I think the underlying question here isn't really about application profiles as
such: it's about whether a DC metadata record must always "stand alone" or
whether we work on the basis that the interpretation of a DC metadata record
depends also on information about the properties/classes used in the
description, which is made available separate from record itself.

Quoting Douglas Campbell <[log in to unmask]>:

> Sorry, I probably didn't explain it very well (probably because I
> haven't got a clear picture in my head yet) so I'll give it another
> go...
>
> I guess I was thinking that APs can be seen as a way to do whatever you
> like yet still say "but it's OK, look, I conform!"  - kind of a cheat's
> way to solve Rachel's "tension between alignment and differentiation".
> I think we're still too early in our use of APs, and the resulting
> records, to understand the implications of having them on the landscape.
>  This is something Stu has been mentioning too.

Maybe I'm reading too much into your "do whatever you like" phrase! ;-)

But it seems to me a DCAP _must_ follow/conform to some sort of rules/model. It
is not, must not be, a license to "do what you like". Otherwise the label "DCAP"
becomes a label to be applied to anything and everything, and is meaningless -
or worse than meaningless, because it implies some sort of commonality amongst
the individual things with that label, when in fact none exists!

> If I have an AP that uses elements from various schemes though only
> uses "dc:source" from DC, technically it conforms to DC, but that
> (dc:source) isn't really much of a DC record (imho)!

I tend to agree, but see below for a qualification...

> What if the AP
> also used an element "another:name" [from the "another" element set]
> which is effectively the equivalent of dc:title - then the DC record
> part in the AP could potentially have had Title and Source, which would
> have made it a more "useful" record in the DC landscape.

... however, the "usefulness" of that record to a DC application is not (IMHO)
dependent _only_ on the information contained in the record itself. I think this
is really the issue underpinning your questions here.

Yes, if the application has access only to the name of the property
(another:name (or the URIref for which that QName is an abbreviation)), then
it's not very useful.

But if the application has access to more information about that property
(either because the human application developer goes and reads it somewhere and
embeds it in the application, or because the application acceses a
machine-processable description on-the-fly) then another:name _is_ potentially
useful - and may turn out to be just as useful as if the record contained a
statement using a dc:title property. More below with your another:name example...

> What I mean is, APs (as we currently know them) steal elements out of
> context.  While there is no such thing as a "typical" DC record, there
> are [I contend] some sort of norms appearing, like if you're going to
> include some typing information you will likely at least include a
> dc:type value from the DCMIType vocabulary.  This is a Good Thing
> because if you collect up a bunch of DC records from multiple sources,
> there is likely to be at least some sort of consistency.  I know DC
> doesn't require these things, but it sure makes for better resource
> discovery applications!

Yes, I think it would be a Good Thing to recommend that a DC metadata
description should include a statement that indicated the type of the subject
resource. I'm less sure the value has to be a DCMI Type class (see below re
subclass relationships)

> So, maybe the DC guidelines for APs (when they emerge) could say
> something like: if your AP includes an element containing data that is
> "pretty darn similar" to dc:X (eg. dc:title), then you should include
> dc:X in your AP, even if it means duplicating another element.  So DCMI
> would say: it's OK to steal DC elements for your AP, but you can't call
> it a DC-conforming AP unless it meets these requirements...?

OK, let's look harder at the pretty-darn-similar-to-dc-title example....

(a) If the property another:name is exactly equivalent to the property dc:title,
then either

(i) you just use dc:title in the first place! (And include a description of the
usage of dc:title and not another:name in your DCAP) ;-)

Or

(ii) you use another:name and not dc:title (and include a description of the
usage of another:name and not dc:title in your DCAP). In the definition of
another:name you declare that another:name denotes the same concept as dc:title
either as a human-readable statement or as a machine-processable statement using
owl:sameAs (or owl:equivalentProperty - I can't remember which is required, and
I know there are quite subtle differences between them.)

You do _not_ need to include the dc:title statement in your metadata description
because an application can infer it either from the information hard-coded into
the application by the developer or from the sameAs/equivalentProperty relation.
The application does not need knowledge of what another:name "means": it needs
only the sameAs assertion and to "know" what that assertion implies. However, I
do recognise that (AFAIK) DCMI hasn't made use of this sort of assertion to date
- and the concept is not included in the current version of the DCMI Abstract
Model (DCAM).


(b) If it is true that _every_ time you say

my:x another:name my:y .

that implies

my:x dc:title my:y .

but the reverse is not true, then you have a subproperty (= DC element
refinement) relation. So you use another:name and not dc:title (and include a
description of the usage of another:name and not dc:title in your DCAP). In the
definition of another:name, you declare explicitly that another:name is a
subproperty of dc:title.

As in case (a) you do not need to include a dc:title statement in your metadata
description because an application can infer it from the subproperty/refinement
relation. The application does not need knowledge of what another:name "means":
it needs only the subproperty assertion and to "know" what that assertion
implies. The concept of subproperty/refinement relation is part of the DCAM (and
of the grammatical principles). DCMI _does_ make explicit subproperty assertions
and it does so precisely so that DC applications can make these inferences.

If the instance metadata creator wants to make that second statement explicitly
in the metadata description rather than relying on an application inferring it
(and have both properties referenced in the DCAP), then OK, that's fine too: but
a "refinement-aware" - or DCAM aware - application does not (IMHO) require it.

With knowledge of the subproperty relation it turns out that another:name is
just as "useful" as dc:title! ;-)


(c) If the definition of another:name is such that only in _some_ cases

my:x another:name my:y .

implies

my:x dc:title my:y .

then it is _not_ appropriate to declare a subproperty relation, and you cannot
infer the additional triple. In this case, yes, you _would_ have to include the
dc:title statement in the metadata description in those cases where it applied
(and omit it in those cases where it did not), and you would include both the
usage of dc:title and the usage of another:name in your DCAP.


OK, yes, I'm aware that I'm being a tad disingenuous in assuming that (a) the
owner of another:name will make this information available and (b) an
application will be able to discover it and make use of it.

But, while I can see the "belt-and-braces" effect, I'm kind of hesitant to take
the approach that we _must_ work on the basis that every DC metadata description
has to "stand alone", i.e. every time I include a statement using a non-DCMI
property which is a subproperty of a DCMI property I _must_ also include a
second statement using the DCMI property, because I can't rely on an application
using the subproperty relationship.

> Now you may disagree with my contention - that there are _no_ norms in
> DC records. In that case, maybe the various DCMI-endorsed APs could
> establish the norms in a consistent way across all of them??
>
> However, this is a wider issue so it shouldn't hold up the DC CD AP.
> What triggered it for me was that DCMIType of Collection is implied in
> the AP (in cld:CLDT), but it will never appear explicitly in any
> resulting DC records that conform to the AP.  This concerns me because a
> "typical" DC application shouldn't have to learn all the peculiarities
> of the multiple DC APs.  Even if they did take account, they can use the
> "refines" instructions in the AP to "dumb-down" the local refinements
> into DC elements, but there's no equivalent information for the encoding
> schemes - maybe the cld:CLDT should include "refines" instructions
> too??

Yes, as I said in an earlier message, the intent is to declare all the classes
in the CLDT vocab to be subclasses of the class dcmitype:Collection, and we need
to make this explicit in the human-readable documentation of the CLDT
vocabulary. This means that _every_ time I say something is of type
cldt:CollectionImage (etc), I also imply that it is of type dcmitype:Collection.
I don't _have_ to make that second statement explicitly in my metadata description.

The concept of subclass is part of the DCMI Abstract Model, and DCMI already
makes exactly such assertions in its declarations of the classes
dcmitype:MovingImage and dcmitype:StillImage, both of which are declared as
subclasses of dcmitype:Image.

That means that every time I find

my:x a dcmitype:MovingImage .

I can infer

my:x a dcmitype:Image .

(In the human-readable DCMI documentation, the subclass relation is labelled
"Narrower than" not "Refines" - I think that is a Good Thing because the
subclass relationship is quite different from the subproperty ("element
refinement") relationship.)

Again this comes down to whether we always see a DC metadata description as
"stand alone" and assume the application has no access to information about the
properties and classes used, or whether we work on the basis that the
application can obtain that information and infer those additional statements.

> I know the CEN guidelines are a huge step forward, but they don't quite
> fit the DCMI community's requirements yet.  I discussed this briefly
> with Tom at the time but they basically had to go ahead and get
> something out.  I floated the idea of a DC-AP Working Group to consider
> the issues, but it needed to wait until after the CEN guidelines came
> out.  Then of course I forgot about it...  :-(

For info, there is a recent draft CEN CWA out for comment that provides (i) a
"conceptual model" for a DCAP and (ii) a suggested means of representing
instances of that model using RDF. See

ftp://ftp.cenorm.be/PUBLIC/ws-mmi-dc/mmidc116.htm

It would be good to have your thoughts on that. Comments should go to Leif
Andresen mailto:[log in to unmask]

Cheers
Pete
-------
Pete Johnston
Research Officer (Interoperability)
UKOLN, University of Bath, Bath BA2 7AY, UK
tel: +44 (0)1225 383619    fax: +44 (0)1225 386838
mailto:[log in to unmask]
http://www.ukoln.ac.uk/ukoln/staff/p.johnston/