I am not sure what you mean by an abstract metadata class.
There is a real distinction between metadata and contracts -- neither
is a specialization of the other (IMO). Think of human contracts: if
you sign a contract, and then accidentally pour some ink over the paper
that you signed; you still have a contract. All that the ink did was
destroy the representation of the contract.
This is what I meant earlier about UML -- it strongly encourages people
to think in terms of specialization. But that is not the only
relationship of interest.
Frank
On Apr 20, 2005, at 1:47 PM, Duane Nickull wrote:
> Would it be fair (and legal) to state that "contract" is a
> specialization of the abstract metadata class and also stereotype it
> as an abstract class?
>
> Duane
>
>
> Francis McCabe wrote:
>
>> The problem with this diagram is that it assumes that a contract
>> *isa* metadata. I could not disagree more. And UML makes this
>> awkward.
>>
>> The relationship between a contract (which is an abstract entity)
>> and its description (which is a document) is one of *describes*.
>>
>> On the other hand, a QoS agreement *isa* contract.
>>
>> I also included the stuff on choreography, business policy etc.
>>
>> I believe that choreography is part of the syntax -- it is part of
>> what you need to know about the mechanics of using the service. But
>> it is separate from business logic and semantics.
>>
>> Frank
>>
>>
>>
>> On Apr 20, 2005, at 2:09 AM, Gregory A. Kohring wrote:
>>
>>> OK, here is a slightly different view using UML. In this view
>>> metadata is the higher level abstraction, while contract is a more
>>> specialized abstraction.
>>>
>>> -- Greg
>>>
>>> Duane Nickull wrote:
>>>
>>>> Francis:
>>>>
>>>> Cool! This is perhaps a place where using UML to avoid ambiguity
>>>> may be
>>>> good.
>>>>
>>>> If I read your diagram, it asserts that "realized as" implies an
>>>> "abstract-concrete" association. I had viewed that the other
>>>> concepts
>>>> are more of a "can be aggregated as part of" association. My
>>>> observation is that usually the abstract-concrete association is
>>>> often
>>>> used for mapping a specific protocol or specification to a concept
>>>> in a
>>>> reference model or reference architecture.
>>>> I guess the question we need to consider is "what is the association
>>>> between the higher level abstract concept of metadata and
>>>> specialized
>>>> metadata concepts?".
>>>>
>>>> Anyone care to take a stab at this as a UML class diagram (or
>>>> answering
>>>> the question)?
>>>>
>>>> Cheers (and beers next week)
>>>>
>>>> Duane
>>>>
>>>>
>>>>
>>>>
>>>> Francis McCabe wrote:
>>>>
>>>>> I prefer the following diagram :)
>>>>>
>>>>>
>>>>> Frank
>>>>>
>>>>> On Apr 19, 2005, at 9:51 AM, Duane Nickull wrote:
>>>>>
>>>>>> <Drawing1.png>
>>>>>
>>> <metadata.pdf>
>>
>>
>
> --
> ***********
> Senior Standards Strategist - Adobe Systems, Inc. -
> http://www.adobe.com
> Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
> Adobe Enterprise Developer Resources -
> http://www.adobe.com/enterprise/developer/main.html
> ***********
>
