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

[Ken Laskey <klaskey@mitre.org>]

Thinking more on this, the critical thing about metadata for SOA is (1)
it is external to the entity and can be viewed and processed without
touching the entity, (2) it contains sufficient information so you can
discriminate between one entity and another.  

Some other words and concepts that may be useful:

Use of the term
metadata has expanded beyond the point of conveying a definitive
meaning when the word is used.  The data model in a database is
traditionally looked at as metadata because it describes the structure of
the database.  Similarly, information included before a table in a
data file can identify the variables represented by the values in the
rows and columns, and this is often described as metadata.
When used in the context of a service-oriented architecture (SOA),
metadata typically serves a much wider purpose.  For the myriad of
capabilities with which metadata has been connected in an SOA context, it
would be more accurately described as that subset of the data related to
an entity that provides some critical descriptive information which is
especially useful in some context for identifying, using, or otherwise
interacting with the entity.  Context is especially important. 
The entity may be a physical object or a computational object, such as a
data set or an application, or anything else to which there is a need to
apply a description.  Any subset of data (i.e., any
information associated with or comprising the entity) may be identified
as metadata if it satisfies the needs for some context, and there may be
multiple metadata sets corresponding to any number of contexts.
Admittedly, this is quite an expansion over the traditional use of the
term.  As an example of the expanded use for different contexts,
consider the ways in which metadata for a book may be defined and
used.  For a librarian, the Library of Congress classification
number is likely an important metadata element.  Conversely, for a
bookseller, the classification number is not likely to be as important
but the current sales price would be (while this price may not be of
interest to the librarian).  The text in the book is unlikely to be
identified as metadata, but specific quotes from  the book may be
metadata for someone advertising the book.

Ken

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