On Tue, 9 Sep 2003, Andy Powell wrote:
> On Tue, 9 Sep 2003, Roland Schwaenzl wrote:
> > Pete wrote
> > > 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".
Is that the same as what used to be called a reification? Wouldn't a
record RDF in that case be the set of assertions that are asserted by the
same creator at the same time. OK, that is an operational definition, but
On Tue, 9 Sep 2003, Andy Powell wrote:
> I define a record as "some structured metadata about a resource,
> comprising one or more properties and their associated values".
This would imply that there is a basically no difference between a record
and a structured value. E.g., a resource has a creator, a title and a
coverage (a structured value) and the coverage has a bounding box (a
structured value comprising two coordinates along the box' diagonal).
> 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?
I don't think so
> > 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.
The question is if our user communities are helped by an abstract model
defining qualified and simple DC, or if we are more helpful if we provide
means for formalizing a record model in general.
> 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
> associated values.
> - 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]
It is not bad. I have to think more about this, and the addition.
Somehow it still seems meaningless to provide an abstract metadata model
which is could applied by others who don't use a single one of our terms.