[
Lists Home |
Date Index |
Thread Index
]
The pro: one language for all metainformation in all documents and messages. Thus,
one handler type, a neat way for engines to mine and make associations, etc. It's
an ultimate spin language.
The con: RDF isn't a thriving technology or language. It has to wrest niches from
pre-existing technologies and languages, eg, UDDI descriptors, HTML metatags, RDDL
XLinks and so on.
So far, RDF and the SemWeb don't have credibility, not because they don't work, but
because other things are doing the job they want to do. So far, those other things
are working. Is there some giant obvious value-add for using RDF in UDDI? A FUD
tactic that says UDDI loses credibility isn't a compelling argument.
I'm not someone convinced the SemWeb has a good business case, or enough technical
edge to consider the costs of retooling all the metainformation niches. It seems
a lot like earlier YON techs (You Only Need: opposite of YAGNI). Also, if it gets
that same religious fervor of earlier HTML days, it could be disruptive at a time
when a disruption won't be well-tolerated; in other words, it becomes a spoiler.
I'd be willing to bet the majority of web systems still rely on basic HTML.
Given the REST issues, RDF incursions, and the problems of trying to integrate an
increasingly diverse set of Internet applications, it makes more sense to me for
Web Services and SemWebs to not converge. Web Services should become XML Internet
Business Services and not be on The Web.
len
From: Jens Jakob Andersen, PDI [mailto:jens.jakob.andersen@post.dk]
Hello
I have been grinding my brain with a dilemma.
What is the big picture as well as pros and cons of:
UDDI
RDF
Semweb
Me thinks that if UDDI would marry RDF, the semweb would suddenly be a lot closer.
We will see some problems with UDDI and e.g. change management of individual web-services, leading to UDDI's being out of sync and UDDI loosing credibility.
What do you think?
Jens Jakob Andersen
|
