Dear Tom,
a little meditation about "silence" (noise and herrings).
Tom wrote>
> > >
> > > The DCAP guidelines address (by analogy) the question of
> > > whether a record could contain zero properties and still be
> > > said to conform, as follows: "A DCAP consists of... one or
> > > more Term Usages." That seems like a sensible criterion.
> > > (By another analogy, one would not say that an English
> > > speaker sitting quietly and not uttering a single word was
> > > "speaking English".)
Don't think this is an analogy - or would you claim: to be quiet
for a moment is non-conformant to English?
RDF doesn't like the graphs, which don't have at least one
arc - but is that a big issue really?
Are you sure the existing XML schema for
simple DC catch the empty worm as an error?
In record 2 below there is a nice qualified DC interpretation of the record -
Would you accept an application as conformant, which is aware of
<my:duration> --subPropertyOf--> <dct:extend>, and treats incoming
records by creating a qualified DC interpretation from those by trying to resolve
relations to DC Terms?
>
> Further comments below.
>
> > Assume that I've defined 2 new properties:
> >
> > - my:price (which has no relationship to existing DCMI properties)
> > - my:duration (which is a refinement of dcterms:extent)
> >
> > I create three metadata records containing *only* the following
> > statements, as follows:
> >
> > Record 1
> > --------
> >
> > <my:price>$25</my:price>
> >
> > Record 2
> > --------
> >
> > <my:price>$25</my:price>
> > <my:duration>25 seconds</my:duration>
> >
> > Record 3
> > --------
> >
> > <my:price>$25</my:price>
> > <my:duration>25 seconds</my:duration>
> > <dcterms:dateSubmitted>2003-09-16</dcterms:dateSubmitted>
> >
> > For the sake of argument, assume that all three examples conform to 'DCMI
> > grammatical principles'.
> >
> > In my view, none of these *is* a 'qualified DC' record. Record 3 can be
> > said to 'incorporate qualified DC'. Record 2 dumbs-down to a 'qualified
> > DC' record, but is not itself a qualified DC record.
In my view all three records have a well-defined qualified DC and a well-defined simple DC Interpretation.
R1: DCQI=DCSI= (the quiet record)
R2: DCQI <dct:extent>25 seconds</dct:extent>
DCSI <dc:format>25 seconds</dc:format>
R3: DCQI <dct:extent>25 seconds</dct:extent>
<dct:dateSubmitted>2003-09-16</dct:dateSubmitted>
DCSI <dc:format>25 seconds</dc:format>
<dc:date>2003-09-16</dc:date>
Then a qualified DC record would be a record, such that it's DCQI
coincides with the original record.
A simple DC record would be .....
It's a different issue how an applications gets aware of on how to
resolve. This issue already enters with the dcterms vocabulary:
As it increases over time it requires an application as able
to learn to stay on track.
When we consider applications, which do not learn,
then we arrive at a different notions:
A dc15 interpretation, will treat all 3 records as "silence".
A dct2001 application would discard/have a problem with dct:dateSubmitted.
It will not be able to perform a dumbdown to dc:date either.
The abstract model does not completely determine the behaviour
of an application....
I don't think that's a surprise.
[Isn't that with browsers and HTML similarly?]
One could imagine applications, which simply store
yet unknown semantics to be treated, when the application
has some spare time to learn [- an often seen behaviour of
humans]: Not the worst strategy [Isn't that still
similar with browsers and HTML - you can save the actual
code and not only that part the browser can render].
An application profile could mean two things in this context:
A commitment of a sender S to stay with a fixed vocabulary and
a commitment by a receiver R on how to treat vocabularies.
Both profiles might or might not contain a perspective of development
over time.
Some S and R application profiles match (interoperate) "better" than others -
no surprise either....
(It's quite common to assume S AND R know about DC15. dct:audience is
already a point of discussion. I know of at least one sender, who does not
use dc:coverage...)
Such scenarios could play on the ground of the same abstract
model. Why not?
[By the way: We're silent about how a sender creates
the content it is willing to send - for good reason.]
Cheers,
rs
|