Xiaoshu,
I agree all your point except the "inseparably" part. I think the
intension
of GRDDL is to bridge, as oppose to merge - the world of HTML/XML
and RDF
world. The former is intended for human and the latter for machine
(for
instance for a better and precise web crawler to understand web
pages). If
the sole intent is to offer RDF description, a simple <link> tag
pointing to
an RDF document will suffice. But using xslt transformation, it
saves the
authors from "repeating" him/her-self.
Interesting point. I have to think this one over. I agree that a
simple <link> to the finished RDF would work as well in many
instances, and I agree with your point about avoiding repetition.
But if that's the sole advantage of GRDDL, I don't see it as a strong
argument in favor of its use. That's why I've always interpreted
GRDDL as something more, namely an early "web-of-trust" standard,
where its use entailed some implicit contract with the rest of the
web regarding semantic intent.
Question #2: Will this work for the case where the instance author
**doesn't** explicitly know the actual RDF triple set up
front, and the referenced extraction transform is actually
acting as a "language processor" to generate triples "that
thereby see the light for the first time"?
I doubt a "yes" answer. SW technologies are designed for
representing rather
than mining the knowledge. For example, someday when SW is matured
enough,
you may be able trust your software agent with your credit card to
help you
find and book your next flight to F2F meeting. I am not sure,
though, how
much you can trust your agent with information mined from free text.
Actually, I completely agree with you here. I doubt it seriously too.
That's not to exclude that some individual out there might
voluntarily entrust his/her semantics to a machine, for some
particular purpose. (For example, a semantic web researcher, who was
doing a live demo project. Or even a doctor who had set up a well-
tuned natural language processor to encode records for a clearly
defined purpose.)
John
