Pete,
Thanks for your very comprehensive reply. Yes it was case (b) that I meant. I think I understand your reasoning. I'd been pondering round this and really asked the question to clear my thoughts.
Actually, sorry, I could have answered the simpler part of the question myself, about the XML attribute / schema. When I looked at the XML schema it was obvious that dcxm:descriptionRef cannot be an attribute of dcxm:description.
I would think that administrative metadata alongside a metadata description about a 'thing in the world' may be quite a common reason to have pairs of related descriptions. [Though I'm not totally convinced that a set of administrative metadata properties is not also a 'thing in the world' - maybe a virtual thing - but I'll desist from going into metaphysics ...]
It seems to me that if, rather than using a non-specific dc:relation property, I could use a refinement such as isAdministrativeMetadataOf (or something shorter!), then that would indicate what the relationship is about. Even better if there were a corresponding hasAdministrativeMetadata.
But for now I'll either use a dc:relation property (with understanding within the user community about what it means and a definition in the application profile). Or I'll use application specific XML attributes.
As you say, when using OAI-PMH the administrative metadata goes in the 'about' section. But for other uses there is a need to bundle the metadata about a thing and the administrative metadata about that metadata into a single XML document to disseminate them as a single lump. A description set containing a pair of related descriptions seems to fulfill that purpose.
Ann
-------------------------------------------------
Ann Apps. IT Specialist (Research & Development), MIMAS,
The University of Manchester, Oxford Road, Manchester, M13 9PL, UK
Tel: +44 (0) 161 275 6039 Fax: +44 (0) 161 275 6040
Email: [log in to unmask] WWW: http://epub.mimas.ac.uk/ann.html
--------------------------------------------------
> -----Original Message-----
> From: DCMI Architecture Group [mailto:[log in to unmask]]
> On Behalf Of Pete Johnston
> Sent: Tuesday, September 26, 2006 6:32 PM
> To: [log in to unmask]
> Subject: [DC-ARCHITECTURE] Administrative metadata (Was RE: Proposal for a
> minimal description model subset)
>
> Hi Ann,
>
> > Your proposed DC-XML-MIN looks good.
> >
> > I have one question about related descriptions / described
> > resource. Your example 19 is showing a description of a
> > textual resource and a description of a publisher agent. So
> > the resource includes a dc:publisher property with a
> > descriptionRef indicating the description of a publisher.
> >
> > What if I have descriptions that are (at least seem to me)
> > slightly more tied together. My particular example would be a
> > description of a resource and a related description that is
> > some administrative metadata about the first resource.
>
> I wrote a long reply and then realised I may be misinterpreting your
> question!
>
> I read your reference to "administrative metadata" as referring to
> "metadata about your metadata", but then I re-read your message and your
> reference to "administrative metadata about the first resource" and I
> wasn't sure that was what you meant after all.
>
> If you want to say that
>
> (a) the document has a title "My document" (descriptive metadata), and
> the document was modified on 2006-09-25 (administrative metadata)
>
> then these are just two statements about the same resource. You could
> provide two statements within the same description. Or you could use two
> descriptions with the same resource URI, in separate description sets
> and exposed to the world as separate records if that approach is useful
> in terms of managing or processing the data. You'd need a resource URI
> to be able to establish that the two descriptions are "about" the same
> resource though (or some other indirect identification method like the
> FOAF "person with this mailbox" approach.) The fact that one statement
> provides what we think of as "descriptive metadata" and the other
> provides what we think of as "administrative metadata" doesn't matter in
> terms of how the information is represented.
>
> And if that was your scenario, then you can ignore the rest of this
> message! ;-)
>
> If, OTOH, you do want to say that
>
> (b) the document has a title "My document" and your description of the
> document was modified on 2006-09-25 (not that the document itself was
> modified on 2006-09-25)
>
> then things get more complicated. Here the subject of the
> "administrative metadata", the resource described by that second
> description, is not "the first resource" (the resource described by the
> first description - the document with title "My document"); it is the
> _description_ _of_ the first resource.
>
> > Is it
> > permissible to use descriptionRef as an attribute of
> > dcxml:description? This would look like:
> >
> > <dcxm:descriptionSet>
> >
> > <dcxm:description dcxm:descriptionId="abc123">
> > <dc:title>My document</dc:title>
> > </dcxm:description>
> >
> > <dcxm:description dcxm:descriptionRef="abc123">
> > <dcterms:modified>2006-09-25</dcterms:modified>
> > </dcxm:description>
> >
> > </dcxm:description>
>
> The short answer is no, that isn't supported by the proposed format.
> I'll try to explain why, but I don't think we can really start from the
> form of the XML instance. I think we have to start from what information
> is to be encoded/represented, couch that in terms of the information
> structures defined by the DCMI Abstract Model (i.e. as one or more DC
> description sets) and then think about how we might represent those
> description sets using XML.
>
> A validating parser using the supplied XML Schemas would (I think)
> reject the instance above as invalid. If the instance was not subject to
> validation, then the instance could be parsed and interpreted as a DC
> description set, but the dcxm:descriptionRef attribute would be ignored
> in course of that interpretation as a DC metadata description set i.e.
> there is no mapping of that XML attribute value to the DC description
> set.
>
> So the resulting description set would be (in DC-Text):
>
> DescriptionSet (
> Description (
> Statement (
> PropertyURI ( dc:title )
> ValueString ( "My document" )
> )
> )
> Description (
> Statement (
> PropertyURI ( dcterms:modified )
> ValueString ( "2006-09-25" )
> )
> )
> )
>
> Which "says":
>
> 1. there exists some unidentified resource (i.e. the first description
> has no resource URI) which
>
> 1a. has a relationship of the type indicated by the dc:title property
> (so "has-a-title", if you like) with the resource represented by the
> string "My document"
>
> 2. there exists some unidentified resource (i.e. the second description
> has no resource URI) which
>
> 2a. has a relationship of the type indicated by the dcterms:modified
> property ("has-a-last-modified-date") with the resource represented by
> the string "2006-09-25"
>
> > Or do I need to introduce a dc:relation property? This would
> > make the second description:
> >
> > <dcxm:description>
> > <dcterms:modified>2006-09-25</dcterms:modified>
> > <dc:relation dcxm:descriptionRef="abc123">
> > </dcxm:description>
>
> This second form is supported by the proposed format, and would (I hope)
> be valid if validated against the supplied XML Schemas.
>
> So substituting this description element for the second description
> element in the example above, then that represents the following
> description set (in DC-Text):
>
> DescriptionSet (
> Description (
> Statement (
> PropertyURI ( dcterms:modified )
> ValueString ( "2006-09-25" )
> )
> Statement (
> PropertyURI ( dc:relation )
> DescriptionRef ( abc123 )
> )
> )
> Description (
> DescriptionId ( abc123 )
> Statement (
> PropertyURI ( dc:title )
> ValueString ( "My document" )
> )
> )
> )
>
> (I switched the order of the descriptions there to make the next part
> easier to write as a set of sentences, but the order is of no
> significance.)
>
> And that description set "says":
>
> 1. there exists some unidentified resource (i.e. the second description
> has no resource URI) which
>
> 1a. has a relationship of the type indicated by the dcterms:modified
> property ("has-a-last-modified-date") with the resource represented by
> the string "2006-09-25"
> 1b. has a relationship of the type indicated by the dc:relation property
> ("has-some-unspecified-relationship-with") with an unidentified resource
> (i.e. the statement provides no value URI and the description of the
> value provides no resource URI), and
>
> 2. that unidentified resource
> 2a. has a relationship of the type indicated by the dc:title property
> ("has-a-title") with the resource represented by the string "My
> document"
>
> Now then, in both of these examples, I think these description sets
> represent "true" accounts of your scenario.
>
> In the first case 1a is a true assertion if the described resource is
> the document, and 2a is a true assertion if the described resource is
> the description of the document. Neither of those assertions tell us
> that there is any relationship between the two described resources.
>
> In the second case 1a and 1b are true assertions if the described
> resource is the description of the document, and 2a is a true assertion
> if the described resource is the document. And furthermore 1b tells us
> that there is a relationship between the two described resources.
>
> However, in both cases, there is no way of determining that the resource
> which it is asserted "has-a-last-modified-date" is specifically _that_
> other description in the description set.
>
> The statements in DC metadata description sets are "about" "things in
> the world", not "things in DC description sets". What the "related
> description" construct in the DCAM description model allows me to say
> is:
>
> The thing-in-the-world described by this description (set of statements)
> here
>
> is related (in the way indicated by the Property URI) to
>
> the thing-in-the-world described by that description (set of statements)
> there.
>
> The DCAM description model does _not_ allow me to say:
>
> The thing-in-the-world described by this description (set of statements)
> here
>
> is related (in the way indicated by the Property URI) to
>
> that description (set of statements) there.
>
> (or vice versa)
>
> Now in the context of some application, we may decide that the "things
> in the world" that we are interested in do indeed include DC metadata
> description sets and DC metadata descriptions (maybe even individual
> statements), so we could assign URIs to those things and create
> descriptions of them
>
> DescriptionSet (
> Description (
> ResourceURI ( <http://example.org/statement/1234> )
> Statement (
> PropertyURI ( ex:isMemberOf )
> ValueURI ( <http://example.org/description/4567> )
> )
> )
> Description (
> ResourceURI ( <http://example.org/description/4567> )
> Statement (
> PropertyURI ( ex:isMemberOf )
> ValueURI ( <http://example.org/descriptionSet/6789> )
> )
> Statement (
> PropertyURI ( dc:creator )
> ValueString ( "Ann" )
> )
> )
> Description (
> ResourceURI ( <http://example.org/descriptionSet/6789> )
> Statement (
> PropertyURI ( dcterms:modified )
> ValueString ( "2006-09-25" )
> )
> )
> )
>
> i.e. the resource identified by the URI
> http://example.org/statement/1234 (I could have added a type statement
> to say it was a "statement" but to save space I didn't) is a member of
> the resource identified by the URI http://example.org/description/4567
> (again could have specified a resource type) which was created by (the
> entity represented by) "Ann", and which in turn is a member of the
> resource identified by the URI http://example.org/descriptionSet/6789
> (again could have specified a resource type) which was last modified on
> (the date represented by) "2006-09-25".
>
> OK, so now we have some "administrative metadata" descriptions, but even
> if I know that the resource identified by the URI
> http://example.org/description/4567 is a DC metadata description, I
> still don't know that it is that specific metadata description back up
> there in your first example.
>
> This is similar to the document case, though: going back to the first
> example, if I have a statement that the resource identified by the URI
> http://example.org/document/abcd has-a-title "My document", that
> statement doesn't tell me anything more about the "content" of that
> resource. It doesn't tell me that it "is" some bitstream.
>
> I think this comes down to a question about the relationship between the
> resource URI and the resource identified by the URI, and I think that is
> outside the scope of the DCAM description model. If I have a URI for
> some resource, then I might de-reference that URI and obtain a
> representation of the resource - in the case of
> http://example.org/description/4567 , that representation might indicate
> which statements are members of that description, but it might not! But
> any such behaviour is, I think, outside what the description model can
> specify.
>
> (The association between the OAI-PMH "about" container and the "record"
> container is another example of how this is addressed outside of the
> scope of the metadata formats used within those containers, I think.)
>
> We touched on this issue briefly in the context of the LOM-DCAM work,
> and there's a message from Mikael at
>
> http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0601&L=dc-ieeeltsc-task
> force&P=820
>
> which (I think?) suggests a similar conclusion.
>
> So basically, I think the answer is that the DCAM description model does
> allow you to provide a description of a description (or a description
> set or a statement or whatever) but it doesn't allow you to make a
> direct association with the thing described - so it doesn't support what
> you suggest in your example (if indeed that's what you meant!).
>
> I was turning over the notion of whether it is possible to build
> suppport for such an association into the XML format even though it
> isn't part of the description model, but I'm really not sure I've
> thought through the logic of doing that. So at the moment, I think it
> has to be "pushed out" to the application to manage those relationships.
>
> > I would prefer to be able to use the more concise first form,
> > but I'm not sure if dcxm:descriptionRef is a permitted XML
> > attribute for dcxm:description.
>
> Pete
|
