I completely understand and agree with the point that Karen & RIchard
are making here. I actually don't think that these views are at all
exclusive, though. I do think that we need to model what DCMI thinks
that bast practices should be, but I think the accompanying user
documentation & relevant DCAM vocabularies can provide best practices
for less interoperable, even poorly designed metadata.
To me, it really comes back to the Dublin Core Interoperability Levels document:
http://dublincore.org/documents/interoperability-levels/
I would like to see us *design* DCAM for levels 3 & 4, but with an eye
toward providing a path for levels 1 & 2 (and even level 0) to find
patterns to move slowly in the direction of the top half of the
picture. I think that my point about the anti-patterns was exactly
that. The antipattern is a level 1 example, but one that could benefit
from a level 1 best practice that could include documentation about
how it could be shifted up to level 3 or even 4 through application of
a set of rules to metadata that's structured consistently.
Maybe I'm splitting hairs, though, and maybe I'm reaching in an
attempt to get a family of DCAM/DCAP & usage specs to do too much, at
the expense of what it should be designed to do well...
-corey
On Sun, Jul 15, 2012 at 9:40 AM, Karen Coyle <[log in to unmask]> wrote:
> On 7/14/12 12:46 PM, Richard Urban wrote:
>
>>
>> But I think this is exactly what makes it an antipattern vs. a
>> pattern that should be modeled in DCAM. If I understand our turn
>> towards looking for examples, they would help inform our modeling
>> decisions. I think we should cast a critical eye on the patterns we
>> find in the wild and test to see if they are good patterns that DCAM
>> needs to accommodate.
>
>
> I agree with this. I think we need to be sensitive to the reality of current
> systems, but if we try to accommodate all of the practices in the real world
> then the DCAM will be no improvement on the current situation. That current
> situation is what it is, at least in part, because of a lack of conceptual
> models that would help people create good metadata.
>
> Any metadata model, in any case, will address only some of the issues of
> metadata creation. DCAM (in my POV) addresses very basic design patterns,
> but cannot force people to use them sensibly. A model is an educational
> tool, not straightjacket. I think we need a good, solid, logical educational
> tool so that folks using ContentDM can at least articulate what needs it
> does not fulfill.
>
> kc
>
>
>
>>
>> I am very good at translating records of this type, but so far,
>> automating that process (formally and generally, anyway) has proven
>> more difficult. I may be try to take a more low-level approach to it
>> this fall. In any case, automated processing of this type looks
>> like it will miss certain kinds of 1:1 ambiguity (especially if we
>> want a more FRBR-like approach of what resources we are referring to
>> even in a simple record like this).
>>
>> I would also say, as much as ContentDM is at fault, it does allow a
>> much more robust vocabulary definition. MJ Han's study of ContentDM
>> found that repositories were pretty explicit when defining
>> properties. The other culprit is OAI-DC model, which is not DCAM
>> compliant IMHO. Development at OAI seems to have moved on to ORE
>> which solves some of those problems, yet ContentDM and other systems
>> have only implemented OAI-PMH).
>>
>> If I understand this correctly, you see DCAP as a way not to specify
>> a "best practice" design, but rather to document the pragmatic
>> compromises that we're forced into? Lower barriers to these kinds of
>> expressions would be helpful, but I wonder if the current DCAP
>> requirements inhibit what could me more light-weight "as-built" kinds
>> of documentation.
>>
>> Richard
>>
>>
>>
>> On Jul 13, 2012, at 4:58 PM, Corey A Harper wrote:
>>
>>> Dear All,
>>>
>>> Following up on my last email, but diverging from the "strings"
>>> vs. "things" example, I think these antipatterns represent really
>>> interesting use-cases for the kind of Application Profile
>>> descriptions we've been discussing. The trouble with the 1:1
>>> anti-pattern, as an exmaple, is that many libraries find themselves
>>> constrained by the systems they work in. ContentDM, for example,
>>> pretty much enforces this anti-pattern.
>>>
>>> But I truly believe that with a fleshed out DCAM/DCAP--complete
>>> with the kind of AP documentation that Jon was encouraging on our
>>> last call--we could illustrate a best practice for making the
>>> *most* of this antipattern, by documenting consistent, repeatable
>>> *patterns* by which the flat example can be constructed to allow
>>> rules that would convert to the description set in Richard's
>>> example.
>>>
>>> <metadata> <title>Mona Lisa</title> <title> Portrait of Lisa
>>> Gherardini, wife of Francesco del Giocondo </title>
>>> <creator>Leonardo da Vinci</creator> <publisher>Musee du
>>> Louvre</publisher> <identifier>Inv. 779</identifier>
>>> <itemIdentifier>http://is.gd/fFbqI</itemIdentifier>
>>> <date>1501-1519</date> <itemDate>2008</itemDate>
>>> <itemSource>TIFF</itemSource> (actually should be <itemFormat>)
>>> <itemType>image</itemType> <format>oil on poplar board</format>
>>> <itemFormat>H. 77 cm; W. 53 cm</itemFormat>
>>> <itemFormat>image/jpeg</itemFormat> <itemFormat>16781
>>> bytes</itemFormat> <itemRights>Copyright 2008 Musee du Louvre/A.
>>> Dequier - M. Bard</itemRights> <metadata>
>>>
>>> In a rule file, I could basically say that properties with no
>>> prefix correspond to the expression entity, and those prefixed with
>>> "item" apply to a related resource of type-x. I'd basically be
>>> giving consumers of my data a set of instructions for converting to
>>> data modelled in accordance with DCAM, and therefore in accordance
>>> with RDFs / OWL / OWL-DL etc.
>>>
>>> There is a *huge* community of practice around using tools &
>>> systems like ContentDM, DSpace & others, and ensuring that each
>>> collection processed in those tools is internally consistent and
>>> rich enough to be converted into a format like this. I'd like to
>>> offer those communities a set of practices, vocabularies (classes
>>> and properties), and docuementation to share the workarounds that
>>> they are forced into, and I think that this is the incredible power
>>> of a renewed effort to re-create DCAM/DCAP/DCDSP and a related
>>> usage guide.
>>>
>>> Thanks, -Corey
>>>
>>> On Thu, Jul 12, 2012 at 4:44 PM, Richard Urban
>>> <[log in to unmask]> wrote:
>>>>
>>>> Karen,
>>>>
>>>> It could, and while this has been my hobby horse lately, I do
>>>> think it goes directly to the heart of our discussions about DCAM
>>>> and it's role within DCMI. Perhaps that's a useful criteria,
>>>> lest this get too bloated.
>>>>
>>>> also, I was following the current transclusion pattern - if it
>>>> proves to be an antipattern we can break this up differently. ;)
>>>>
>>>> Not sure what to say about DCAM/DCAP divisions. I hadn't intended
>>>> to suggest that the division needed to blur. As an
>>>> interconnected system, talking about both together here seemed
>>>> natural to me.
>>>>
>>>> - Richard
>>>>
>>>>
>>>> On Jul 12, 2012, at 3:46 PM, "Karen Coyle" <[log in to unmask]>
>>>> wrote:
>>>>
>>>>> Ah, that page could get to be very, very long :-).
>>>>>
>>>>> If I can throw in another issue/question while I have my
>>>>> fingers on the keyboard, do we need/desire a dividing line
>>>>> between DCAM and DCAP? One existed before, but I am perceiving
>>>>> a blurring of that line, perhaps willful in nature.
>>>>>
>>>>> kc
>>>>>
>>>>> On 7/12/12 11:09 AM, Richard Urban wrote:
>>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> I've added a section to the Design Patterns page to discuss
>>>>>> antipatterns which may help us identify issues that need to
>>>>>> be addressed in DCAM revisions. Discussion of this may wait
>>>>>> until we're through hashing out ISBD issues, but now there
>>>>>> is a place for others to add similar antipatterns.
>>>>>>
>>>>>>
>>>>>> http://wiki.dublincore.org/index.php/DCAM_Revision_Design_Patterns#Antipatterns
>>>>>>
>>>>>>
> Hadn't
>>>>>>
>>>>>> Cheers, Richard J. Urban, Assistant Professor School of
>>>>>> Library and Information Studies College of Communication and
>>>>>> Information Florida State University
>>>>>> [log in to unmask] <mailto:[log in to unmask]>
>>>>>> @musebrarian
>>>>>
>>>>>
>>>>> -- Karen Coyle [log in to unmask] http://kcoyle.net ph:
>>>>> 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
>>>>>
>>>
>>>
>>>
>>> -- Corey A Harper Metadata Services Librarian New York University
>>> Libraries 20 Cooper Square, 3rd Floor New York, NY 10003-7112
>>> 212.998.2479 [log in to unmask]
>>>
>>
>
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
--
Corey A Harper
Metadata Services Librarian
New York University Libraries
20 Cooper Square, 3rd Floor
New York, NY 10003-7112
212.998.2479
[log in to unmask]
|