[
Lists Home |
Date Index |
Thread Index
]
On 1 Dec 2004, at 19:33, Bullard, Claude L (Len) wrote:
> From: Khalil Ahmed [mailto:kal@techquila.com]
>
>
>> A lot of things that UDDI has tried to achieve could be done with a
>> topic map. The question is if that is the right thing to do. From the
>> point of view of a registry of services and a query interface for
>> retrieving information about those services, UDDI is already in that
>> space. How well embedded UDDI is I don't really have a good feel for -
>> and so I would (personally) feel cautious about making proposals to
>> throw it all out and start again with topic maps!
>
> I doubt any of us has the clout to throw it out and start over. But
> the applicability of topic maps to this kind of task is intrigueing
> given one might want to index the content that UDDI has into broader
> and narrower contexts.
I agree completely. Its really as much about (if not more) about
creating useful structures for the management of the services as it is
about having some standard interchange / registry mechanism.
>
> Cool. What is your experience in the time/tedium of creating
> topic maps?
>
Well, I'm a bit of a fanatic so YMMV :-)
The whole Pepys thing is created by hand - most days I do one or maybe
two entries, using LTM notation (Ontopia's text-based syntax). Thinking
time + typing time + fixing up references comes to about 1 - 1.5 hours
for each entry. About a third of that is fixing up time and less than a
third typing time. Eventually the pain will make me write some better
tools than my current "just use emacs" approach. Merging means I can
work on the map in chunks which makes for a much faster debug cycle,
but introduces its own problems of references between modules. There is
some tedium, but then when you whack the whole lot together it all
becomes worth it.
Of course, I'm a fanatic. YMMV ;-)
>> Of course, I'm still contemplating what I bent some ears
>> with at XML 2004: the notion that a uniform set of human
>> rights should be created for the WWW based perhaps on an
>> ontology of event types. It seems to me that event types
>> are a core piece of Daconta's venn diagram intersection
>> of 'relevance'.
>
>> That sounds interesting - though the notion of creating a uniform set
>> of human rights is far more problematic than an ontology of event
>> types
>> (and the ontology bit is hard enough!)
>
> No doubt that is so. Event types are a core piece of any public safety
> dispatch system, and many legal constraints on events such as search
> and seizure, opening private records, etc., are couched in terms of
> event types. So in many real world ways, the system already works
> like that. It simply isn't always in machine processable form and/or
> casual reader form. On the other hand, it might be a nice service for
> an OnStar-like system to provide given how much the car knows about
> the context of its own performance (eg, speed) and what it can obtain
> from the intelligent transportation systems that are observing it.
> You see, tomorrow is today and our tech is outracing our legal system.
>
> Many don't want to think seriously about these issues. As a result,
> only a few will. Perhaps this is unavoidable, but I'd like to believe
> that open clusters of open thinkers will take up the task before the
> technology is fielded. Perhaps John Cowan is right and we have to
> screw one up first before we design one correctly.
>
Certainly - although there are probably any number of screwed up
event-based systems that could be learnt from if the implementers are
willing to talk about them. I'm thinking of thinks like international
shipping systems and warehouse tracking systems which deal with lots of
events on the input - I would wager (a small amount) that there must be
some implementations which try to manage the events, rather than the
effects.
Cheers,
Kal
|
