[uf-discuss] seeking clarification w/r/to hCard and RFCs 2425/2426

[C. Hudley]

On 3/27/06, brian suda <brian.suda at gmail.com> wrote:
>
> What are you trying to accomplish with directories that would be out of
> the scope of hCard?

Like I said: things like protocols and data formats.  Version and
revision numbers.  Publication dates.  Specification names and
standards organization references.  Arbitrary names of
services-people-deliver that aren't standard in any way.  Some of it
could fit into hCard but other parts would be an awkward fit at best.

This would be in the context of service discovery: for some resource,
or for some organizational context, show me a directory of available
or relevant services.  If you're familiar with OpenURL resolvers, I'm
thinking of something like their result screens, but bigger, and with
a usable design and the option to machine-parse reliably.  Which is to
say, not really like current OpenURL resolver result screens.

I don't really want to drop down to UDDI or whatnot... something
user-centered is better.  Though, I guess stuff like the UIs based on
UDDI-driven services in apps like contemporary GIS tools with
directories of remote data layers and remote feature processors might
be the best examples I know of a current setting where something like
what I'm after actually works and has a decent UI.

I don't want to try to convince anyone here that there needs to be a
microformat for this stuff... I'd just like to know if anybody's tried
to do something like this already and whether they chose to "just use
hCard" or something else or not at all.  And, if it would definitely
be wrong to "just use hCard".

My hunch is that it would be wrong because most hCard processors
likely expect to see information about people and organizations, not
information about services and data and stuff.  But my instinct is to
try it anyway.

Thanks.