On Tue, 9 Sep 2003, Roland Schwaenzl wrote:
> Pete wrote
> > My view of a "metadata record" is that it is a specific set of
> > assertions, created as a set. In the context of an application, it _may_
> > be important to record (and to present to a user) the fact that this set
> > of assertions, now stored along with n-million other assertions, were
> > made together as a unit.
> I tend to agree -
> > To do this, I'd need to store along with the
> > assertions some explicit indication of the fact that the specific
> > assertions that form my set/record are related (e.g. came from a common
> > source RDF/XML doc on the Web) - I think in the RDF context this is
> > described as "context" or "provenance".
> It's in that direction, when one wants explicitly express, who said something.
> (Statements about statements).
> But I think the question Stu asked "What makes a record a record" is pointing in a different
> direction - also the way the term "record" is used by Andy to me appears different.
I define a record as "some structured metadata about a resource,
comprising one or more properties and their associated values". It
doesn't seem to me that my definition is much different to Pete's, which I
think you are agreeing with?? Perhaps I'm missing something?
> They both seem to go for, which contribution a GIVEN collection of statements is supposed
> to make to answer "simple" questions -
Are you referring to my definition here? Sorry, but I really do not
understand what you are getting at. How does my definition indicate a
"GIVEN collection of statements"??
I do agree that my definition of a "qualified DC metadata record" does
indicate a given collection - largely because I see 'qualified DC' as
being an application profile that happens to take all its properties from
DCMI namespaces. Metadata applications are, by and large, concerned with
metadata records made up of given sets of properties.
As I said yesterday, I am tempted by Roland's suggestion of documenting an
'Abstract DCMI Metadata Model' (which doesn't restrict the properties that
can be used) then refining it into abstract models for 'qualified DC' and
'simple DC' - but that, for me, would still leave 'qualified DC' meaning
an application that only uses properties from DCMI namesapces.
Applications that mix properties from DCMI and non-DCMI namespaces might
conform with the DCMI abstract model, but they wouldn't be called
'qualified DC'. They'd be called something else, like 'UK eGMS' or
'RSS-Events' or 'DC-Education' or whatever. Such applications might be
said to incorporate 'qualified DC', but they wouldn't *be* 'qualified DC'.
The alternative is to use 'qualified DC' as the label for the abstract
metadata model that allows any property to be used. The model would be
along the lines of:
- A qualified DC record is made up of one or more properties and their
- Each property is an attribute of the resource being described.
- Properties may be repeated.
- Each value may be identified by a value URI.
- Each value may have a value string.
- Each value string may have an associated encoding scheme.
- Each encoding scheme is identified by an encoding scheme URI.
- Each value string may have an associated value string language (e.g.
- Each value may have an associated rich value (some marked-up text, an
image, a video, some audio, etc. or some combination thereof).
- Each value may have some associated related metadata.
Possibly with the addition of:
- At least one property in the qualified DC record must be one of
the elements or element refinements defined by DCMI [DCTERMS]
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell/ +44 1225 383933
Resource Discovery Network http://www.rdn.ac.uk/