I just reposed a modified version of the diagram here:
On Oct 31, 2006, at 4:50 PM, Robert Tansley wrote:
> In fact, I recall that we decided that metadata was considered "part
> of" the object (Item, Manifestation, Content File) being described,
> and that an identifier for one of those parts (including for a
> particular revision) would enable one to obtain that metadata.
I think this is "at least" the case too. But my concern is that the
meta-metadata issue is going to bubble up repeatedly as an important
thing to represent, maybe the abstract model should assure at least
room for more complex metadata structuring, including clearly
defining if some sort of referencing can be assured by the model.
Given that we are attempting to capture more complex structured
metadata somewhere (which may be left up to the implementation) then
it is important to provide a UML class specifically for it because we
know that metdata can be much more complex than a flat fixed set of
fields or a "property" of a "class"
John Erickson forwarded this paper to me to read. Once you get
through the discrete mathematics definitions you'll find some
interesting tidbits about "structural metadata" that may be important
in our discussion:
On Nov 1, 2006, at 4:56 AM, Richard Jones wrote:
>>> We didn't
>>> really drill down to whether we'd allow "multiple inclusion";
>>> personally I like the idea of each container having one "owning"
>>> container (w/ no cycles) but linked into others.
>>> Metadata class can have its own children? This isn't something we
>>> discussed, as far as I can recall...
>> This comment may have slipped under the radar of the group when
>> Jones made it (hope I'm attributing it properly to him?). Think of it
>> this way, if your going to allow metadata to be a file, then files
>> both dc.format.extent and dc.format.mimetype, so it makes sense to
>> these sorts of descriptive meta-meta-data to be attached to a meta-
> I don't recall whether I stated this explicitly, but somewhere
> along the
> line it did come out ;) The solution proposed was a "lowest common
> denominator" (where else have we heard that term!) set of metadata
> supported natively by DSpace, and for the item (and this solution was
> proposed repeatedly by me, but is really an implementation issue) to
> have a manifest of a well-defined internal format that allows us to
> track of which metadata belongs to which level of the model, and,
> indeed, which metadata describes which other metadata. You can only
> overcome the infinite regression of meta-metadata by defining a top
> level and refusing to back up any further.
Maybe I'm not groking this, why isn't attaching metadata associated
with a particular item, manifestation, or content enough to capture
which metadata belongs to each level? Isn't it inherent in the
structure? Everything we are doing so far suggests to me that we are
trying to get "away" from "manifest" like metadata and rely on the
Data Model to find the metadata.
> Also, we need to be careful with our terminology here. Using words
> Object, Class, Inherits or Extends sound concrete to me, but we are
> using them in the abstract model.
We have to start using UML class diagrams to capture even the
Abstract Data Model, eventually, yes many of these abstractions may
end up in the concrete model as well. Using Class diagrams first
gives us a fixed and well defined set of terminology upon which to
describe the relationships between different parts of the model and
second, by restricting to using this terminology, will allow for an
easy transition from abstract to concrete. In the Abstract sense,
using Classes, Inheritance and Associations says nothing about what
will end up in actual code in the concrete end.
Mark R. Diggory
DSpace Systems Manager
MIT Libraries, Systems and Technology Services
Massachusetts Institute of Technology