[
Lists Home |
Date Index |
Thread Index
]
Eric Hanson (elh@cs.pdx.edu) wrote:
> Michael Champion (michaelc.champion@gmail.com) wrote:
> > Can you imagine standard that would meet your needs and be broad
> > enough to be widely adopted across the various religious divides (WS
> > vs REST, document vs data, RDF vs straight XML, etc.) in our little
> > world? What would a single standard offer that the existing toolbox
> > full of stuff that could be applied to this problem would not?
>
> IMHO, nothing would be gained from mandating any single
> interface to the data. In fact I think it would be very hurtful
> to limit it at all.
I missed a couple of interesting points you made, sorry. Here's
a little better response, hopefully.
There are a bunch of issues and angles here, it's kind of
complicated.
WS vs REST, sorry I don't know much about WS. But if you're
talking about standardizing the interface, yeah, I'd say lots of
interfaces are fine, as long as there's a REST one for me to
use. :-)
Document vs. data, there are already some mechanisms aimed
mostly at the document world that link a document related
resources -- at least in a limited fashion. When a XML document
links to a stylesheet or a schema in the header, that links the
data to a couple of related resources. For the document world,
this might be sufficient. If so, great. If not, a resource
discovery infrastructure would just be another tool in the
toolbox. It's important to note that a system like this
wouldn't require any changes in XML at all. It just augments
the architecture.
XML vs RDF, there's two different angles here, whether we're
talking about XML vs RDF as the data objects, or as the
description of the resources.
As data, the approach to RDF resource discovery is a little
different then for XML. In XML, a QName serves as the unique id
for a datatype, so resources should be associated with this. In
RDF, things are a little fuzzier. There are a few options for
representing datatypes. Two notable ones are OWL classes and
RDF schemas. The unique ids for these are just URIs, no QName.
XML vs RDF for resource descriptions, I think that using RDF is
the right way to go for the reasons you pointed out. This is an
entirely general problem that literally spans the breadth of the
question "How can data be used?" Any attempts to pigeon hole
this or develop a rigid silver bullet standard upper ontology
would just limit the system. RDF is I think sufficiently
general and extensible and after all, it is a resource
description framework. :-)
That said, there are a few common elements that would probably
be useful across many resource types -- I think RDDL's nature
and purpose are a good starting place for describing a resource.
For example, when describing a XSLT that transforms a document
<foo> to HTML, you could set the resource's "nature" to XSLT's
URI and its "purpose" to "display"'s URI.
Beyond this, the description vocabulary is specific to the type
of resource. An XSL transforation like the one above would need
to include the target mimetype, in this case HTML. A RELAX NG
schema would have a nature/purpose of relaxNG/validate but might
need another vocabulary item that says whether its in compact
syntax or verbose. Etc, etc.
Eric
|
