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
|
