OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-editors message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm-editors] what is metadata?


Ken:
   I think that this is a storm in a tea-cup.
   Furthermore, I think what you are referring to in non-machine  
processable metadata is really descriptions.
   More concretely,
1. whatever your employers' feelings might be, services will include  
a significant element of automatic discovery. Consider something  
prosaic: managing a set of services within an enterprise that have  
redundancy in them. Or needing to be managed.
2. in a system's integration environment you can model the enterprise  
architecture in terms of discoverable services. It is a sound  
strategy for evolvable systems. On the other hand, you don't have to  
worry about complications arising from contracts between commercial  
partners.
3. do not confuse metadata with OWL or OWL-S descriptions :)

There is more but I'm a little sleepy ..)

Frank


On Sep 12, 2005, at 11:36 PM, Ken Laskey wrote:

> One of the things I'm not comfortable with in 08 is the discussion  
> of metadata.
>
> First, a perspective from my sponsors, not necessarily my  
> perspective but one I need to keep in mind.  It goes like this:
>
> SOA is great and wonderful but they really don't believe this  
> automation crap.  We will have governance boards and we'll vet  
> services and we'll tell you which ones to use.  We'll have a  
> registry to catalog services but we really don't believe this  
> dynamic composability line either.  But we do know metadata because  
> we've fought with it before and the Net-Centric Data Strategy says  
> metadata is the answer to our problem.  Yes we want visibility and  
> we want discovery, and we will get it because we'll insist  
> everybody create metadata.
>
> Now that is my audience, and if my lead is metadata for wondrous  
> automation, they'll look at me like I have six heads.  I'm afraid  
> the same will happen in many other user communities.
>
> Now to give you my perspective, not completely free of theirs but  
> knowing what they say has some ring of truth for every user community.
>
> The purpose of metadata is to provide description for whatever  
> purpose description is needed.  As Frank notes, it doesn't have to  
> be perfect description but it has to be good enough for the  
> purpose.  It also needs to be as unambiguous as possible, and this  
> is where connecting the metadata to a clearly defined semantics is  
> necessary.  We do not have to define that semantics (other than as  
> relates to the RM) but any SOA implementation (or probably even RA)  
> has to support a mechanism to indicate what semantics someone is  
> using.
>
> Now will that eventually give you better automation capability?   
> Definitely, but I can't lead with that as my driving rationale  
> because it smacks too much of over-promised AI.
>
> Is the metadata machine-processable?  Probably not initially but,  
> again, this should increase over time as will the capabilities it  
> enables.
>
> The biggest point we can make is that there is likely no one  
> correct and complete set of metadata for an entity and your SOA  
> should be able to make use of multiple sets that are designed to  
> support different purposes.  These sets will likely overlap and  
> part of the strength of your SOA will be how well you can make use  
> of combinations of metadata.  I happen to think it will be  
> necessary to manage inconsistencies and uncertainty, but I wouldn't  
> push to go there for the RM.
>
> A side note: I think we need a list of pet points each of us would  
> like to make in the RM and then discuss whether the points should  
> be included separate from where or how these would show up.  Some  
> of my pet points have disappeared and the spec is better for it.   
> There are a few I'd like to argue make it back in.  My sense is we  
> could have a much more productive editors meeting now with that  
> discussion than what was possible before 08 was written.  But we  
> are where we are and I'm looking for an efficient way to move forward.
>
> Other ideas?
>
> Ken
>
>
> ---
> Ken Laskey
> MITRE Corporation, M/S H305     phone:  703-983-7934
> 7515 Colshire Drive                        fax:        703-983-1379
> McLean VA 22102-7508
>
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]