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?


Frank (and others) - see below

On Sep 13, 2005, at 9:25 PM, Frank McCabe wrote:

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.

Metadata is description.  Machine-processable metadata is description readable by humans and machines; non-machine-processable is only readable by humans.

  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.

Automatic discovery will be more of a dream than a reality until we have reliable ways for machines to formulate questions to other machines and then correctly interpret the answers.  As far as a set of services with redundancy, there is this schizophrenic paradigm of we will search for services but of course we will manage to eliminate overlap because that is wasteful.  This is around a lot in the business and governance side of the literature.  So the unspoken assumption is that I have an unspecified way to formulate question but there will only be at most a few answers.  BUT, if we can get people (or systems) to create the metadata and we can push toward more machine-processable format, the users will gain the dynamic capability whether they initially intent to or not.

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.

Oh I agree with the appeal of seeing enterprise architecture in terms of discoverable service.  I think I contributed something early in the TC showing just that.  But until you can unambiguously specify constraints and policies I'm not sure you'll have any less contract complications.  Even then, much of the contract complications is due to human processes and a metadata representation of what humans are haggling over will be no less messy no matter how elegant the metadata.

3. do not confuse metadata with OWL or OWL-S descriptions :)


Don't think I am but if you have an example of where you think I am, I'd be happy to reconsider my position.

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

Sleep well.


Frank


Ken


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







---
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]