Hi David,
> Very glad to join this list. I am developing an
> education-focused metadata application profile, with the
> foundation of Dublin Core and the addition of several local
> elements. I'm finding the discussions, particularly regarding
> Audience vocabulary, to be very relevant to the work I'm doing.
>
> In developing local elements, to be intermingled with DC
> elements, I'm running up against the question of whether to
> create elements or refinements
> - both in the case of a local element and its local
> refinement, and a local refinement to a DC element.
>
> From DC documentation on refinements, I understand that the
> refinements provide a more specific or narrow meaning, should
> act as an 'adjective' to the element's 'noun', and don't
> expand the scope of the element - and that the "dumb down
> principle" means a value of a refinement should make sense if
> someone simply sees the value as that of the refinement's
> parent element.
I'd be a bit wary of pursuing the adjective-noun analogy too far. I
think it's probably better to think in terms of both the "element" and
the "refinement" fulfilling the _same_ "grammatical "role", if you like,
rather than two different "roles".
They are both "properties"; they both express a type of relationship
between two resources. Rather than thinking of the refinement as an
adjective to be applied to the element as "noun", it might be more
useful to think of it as a "specialisation" of the element. Both are
relationship types, but one is a more specific type of relationship than
the other, e.g.
Document D is-associated-with-date "2008-07-03"
Document D has-creation-date "2008-07-03"
If you know that a specialisation relationship exists, then if you
encounter a statement that the more specific relationship exists between
two things (e.g. my second statement above), then you can conclude that
the more general relationship also exists between those two things (e.g.
my first statement above) - and that applies in all cases, regardless of
what my statement is "about".
To be fair, the naming convention DCMI historically used for properties
has rather fostered the "noun/adjective" metaphor (e.g. giving
refinements names like "created", "modified"), but more recently, the
convention has been to give properties names which emphasise more the
"stand-alone" nature of the property ("dateAccepted" etc).
> What I'm grappling with is how this plays out in actual,
> real-world applications. For example, take the DC element
> Date and the various refinements - Date published, Date
> approved, etc. If the metadata for a resource had
> <dcterms.dateapproved>2000-04-01</dcterms.dateapproved>, for
> example, how precisely would a system that did not recognize
> this refinement know to roll up the value to Date?
It depends essentially on the system having access to some information
that tells it explicitly that
example:dateApproved is-refinement-of dc:date
Or formally using the RDF Schema language:
example:dateApproved rdfs:subPropertyOf dc:date
You could imagine various ways by which the system might obtain that
information:
- it might be "built in" to the application by the developer - but
obviously that only works for a finite set of terms which the developer
knows about. If new terms are added to the dat being processed the
program has to be amended
- it might be provided in some sort of configuration file that is
provided at run time - again that depends on someone obtaining/providing
the info, and updating the config file has new terms are added to the
data processed by the system
- the application might "look up" the information on the Web as required
In RDF (and Dublin Core) metadata, properties are identified by URIs. If
the URI is associated with a mechanism for dereferencing the URI - e.g.
if the URI scheme chosen is associated with a network protocol - then an
application can perform an operation on the network to obtain some
information about the resource identified by the URI. All DC metadata
terms are identified by http URIs, so an application has the option of
performing an HTTP GET on the URI. And DCMI makes available descriptions
of its terms in machine-readable form, and serves those descriptions
over HTTP.
So e.g. the URI for the DCMI "date created" property is
http://purl.org/dc/terms/created If I do a GET on that URI, (e.g. put it
in my browser address bar), then I get back an RDF/XML document which
includes a description of that property (the document includes
descriptions of lots of other properties too, but that's OK), and that
data includes the information that
dcterms:created rdfs:subPropertyOf dc:date
And the same could apply for some "local" refinement that you create.
I.e. you can publish a description of your refinement of dc:date and say
my:dateDiscovered rdfs:subPropertyOf dc:date
That way my application (and every other application out there) doesn't
have to maintain its own set of term descriptions (either in the program
code or in a config file): all those applications can make use of the
Web itself to obtain that information (and any other information the
term owner wants to provide).
Of course, that approach only works if the owners of the terms make
descriptions of their terms available in this way. It isn't an absolute
requirement - I can use the URI http://purl.org/dc/terms/created in my
metadata to say when my document was created without relying on that URI
being dereferenceable - but it is considered "good practice" for term
owners to do so. And e.g. the W3C have some guidelines for how to go
about it here
http://www.w3.org/TR/swbp-vocab-pub/
and I think what DCMI does more or less reflects the guidelines there.
> Furthermore, what is the function of element refinements in a
> closed local system which the metadata creator controls (in
> other words, no need to 'dumb down' since all work is
> happening in one place) - if any - versus simply having
> separate elements? Does having this hierarchical relationship
> among elements/refinements serve any purpose?
It may still be useful to be able to infer the additional statements, I
suppose: it really depends what you want to do with the data, I think.
Pete
---
Pete Johnston
Technical Researcher, Eduserv Foundation
[log in to unmask]
+44 (0)1225 474323
http://www.eduserv.org.uk/foundation/
http://efoundations.typepad.com/efoundations/
|
