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
|
