[
Lists Home |
Date Index |
Thread Index
]
Jonathan Borden (jonathan@openhealth.org) wrote:
> > It's a complex problem that tries to take into account all the
> > ways an instance can be used! Such is the nature of
> > generalization...less than trivial, and I sure don't have it
> > figured out.
>
> RDDL provides *a* solution to this problem, namely that you resolve the
> namespace URI, get back a representation (document) and this tells you
> something about the namespace.
>
> An RDF triple store might provide, assuming some things were worked
> out, a different mechanism for finding out about a namespace URI e.g. a
> triple store might contain various triples that reference the URI.
Before deciding on RDF or any other data format, I think it's
important to figure out the structure of a resource description.
If a resource can be sufficiently described using a tree
structure, forcing users to author it in a graph language would
be IMHO a big mistake.
I have a lot of thoughts about RDF and why I think many of the
benefits of RDF can be achieved in a simpler and more elegant
fashion using plain XML with schema languages that lend
themselves to extensibility, but I'll try to avoid that rant for
as long as possible :)
> If you read through the xml-dev archives, we had very early on
> considered including a mime-type property -- actually this was my
> initial suggestion, but then we decided this was redundant -- the
> nature can serve as a URI encoding of a mime-type as is described in
> the RDDL document.
This is the mime type of the resource itself, no? In the case
of a transformation, there is a second mime type for the results
of the transformation. This I guess should be refered to as
"target mime type", not just mime type.
So the only use of target mime type that I can think of is with
transformations. There surely are other properties that would
describe resources of a certain nature but not be appropriate
for other natured resources. It lends itself to greater
granularity beyond nature and purpose: All resources have a
nature and a purpose, but beyond that maybe the structure of
descriptions should be tailored to resources of that nature.
> A key, perhaps *the* only unique characteristic of RDDL is that it is
> intended to be human readable. If you drop the requirement for human
> readability RDDL is an utter waste of time, and you'd be far better of
> using RDF directly.
But there's still a spec here to be written. Even if RDF was
decided upon, there has to be some kind of standardized way to
describe resources beyond anyone can say anything about
anything.
I like RDDL as a starting place, but maybe what I'd like to see
is some kind of sister spec for non-human-readable RDDL.
Also, if an RDDL doc is decoupled from the namespace URI, yet
still expected to be associated with it, it's no longer just a
resource directory description. It's a resource directory
description /about a namespace/, and it has to include the
namespace as part of the doc's data. So maybe it's a different
spec all together.
Eric
|
