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?

   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  
3. do not confuse metadata with OWL or OWL-S descriptions :)

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


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]