Hi WGers,
(I apologize for one last cross-posting. We've had a very important discussion here that has truely been cross-cutting, so I thank the non-participants for their patience.)
I feel this week's threads winding down, so it might be time for some summarizing words. We have talked about three issues that are clearly interrelated.
In hopes of providing some useful things to think about going into next week, here are some summarizing thoughts.
o I think we all agree that retrieving metadata from the service
is a good thing. It gives the service provider greater ease and
control to keep the information up to date. It also makes it easier
to register the service because there will be less form-age to deal
with. The questions needing answers are:
a. should the service export a complete VOResource description,
as in VOSI's getRegistration()?
b. should the service export only the capability metadata, as in
DAL's getCapabilities()?
c. is there a way to provide both in a consistant way that doesn't
confuse everyone involved?
o Note that I didn't say anything about grain-iness or table
metadata above. This is, I believe, a separable issue; that is,
answering these questions do not address the grain-iness issue.
o At the heart of the fine-grained metadata issue is the method we use
to share metadata: registry harvesting. If reputed fine-grained
information gets into the harvesting stream, it will tickle this
controversy. More importantly, if we expect the information to be
there, it will irritate the controversy.
o We need a common understanding of what fine-grained means. We may
not agree on what information falls into that category, but if we
know its characteristics, we might develop some general strategies to
deal with it.
I have some thoughts on this, but I won't get into them here. We
will discuss it in a Registry session, and I hope to capture our
thoughts in an IVOA Note.
o With issue #3 above, I proposed a common way to get at table
metadata without explicitly including it in the VOResource record
that enters the harvesting stream. It involves putting a URL in
the record that points to the table metadata encoded in a standard
format.
Tony suggested that the VOSI standard provides the same solution. So
the questions that remain are:
a. Can the VOSI interface indeed allow a registry to sufficiently
limit the fine-grained metadata it has to contend with.
b. Could VOSI be altered to enable this?
c. Can either Ray's suggestion or VOSI point to a general solution
that can be applied to other information that might qualify
as "fine-grained"?
o Finally, the graininess issue points to a larger issue of how we work
together in the IVOA. Personally, I feel that it should be an
important principle of the IVOA that VO projects should be free to
innovate new ways to meet the needs of their communities, but they
should do that in a way that doesn't prevent other projects from
doing the same at the cost of interoperability.
Note that I want to emphasize the part about what projects CAN do,
not the CAN'T.
Furthermore, we need to keep each other informed about the cool stuff
we are doing. In this way we can identify early opportunities for
interoperability and avoid harmful fragmentation.
hope this helps,
Ray
Received on 2007-05-09Z22:02:38