[
Lists Home |
Date Index |
Thread Index
]
Jonathan Borden (jonathan@openhealth.org) wrote:
> Eric Hanson wrote:
> > Jonathan Borden (jonathan@openhealth.org) wrote:
> >>> Yeah ok, centralized probably isn't the right word here, and I
> >>> didn't mean to imply that the language itself is centralized.
> >>> Just I think there needs to be a way for third parties to
> >>> associate resources with a namespace in such a way that they can
> >>> be found using just the namespace.
> >>
> >> OK, what are the rules by which this process is carried out. Who gets
> >> to arbitrate when there are competing visions of what is associated
> >> with what. Decide this, and you can pick which system to use.
> >
> > I was thinking like you describe below, priority goes to
> > resources coming from the namespace in question, but allow for
> > local override.
> > ...
> >
> > Heh, ok, well, I'm almost done with the implementation using
> > neither RDF or RDDL. I used just vanilla XML, but with a note
> > that the project at this stage is experimental, and using RDDL
> > or RDF in the future might be a good option. Using an RDF store
> > sounds pretty interesting.
> >
> Since you are already implementing this, you have already worked out
> the rules by which who gets to say what about the namespace.
Anyone can say anything about a namespace. The rule that isn't
worked out is who will listen to them and how they will listen.
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 would just be a replacement for your "plain vanilla XML"
> and wherever you have an XML document you could replace that
> with a RDDL document. RDDL is just a simple extension of XHTML
> -- that is you create documentation of the namespace readable
> by humans using HTML and readable by your program using the
> RDDL extension vocabulary.
The data in the two formats is pretty similar. Typekit uses
nature and purpose as well. It adds one more property,
mime-type, which indicates in the case of a transformation, what
the target mime-type of that transformation is. This property
is optional however.
I'd like to find some kind of harmony between RDDL and typekit,
so let me lay my cards on the table and say what I do and don't
like about RDDL.
Pros:
* functionally, RDDL does a lot of the same things typekit does,
and it's developed here.
* nature/purpose is I think brilliant starting place for
generalizing the description of a resource.
* the name RDDL is a descriptive name for what I've been calling
a typekit descriptor.
Cons:
* RDDL is an extension of XHTML, which joins data and
presentation in a way that IMHO would be better accomplished by
browser support for intelligently displaying XML. Granted, this
support doesn't exist currently, but I think it could using
something like this project.
* RDDL is already an emerging standard, and it's a little
different from the direction typekit is headed. Part of the
reason for inventing a new spec with some overlapping goals is
to have a place to experiment and try new things without having
to worry about an existing standard.
Unsure:
* Why RDF?
That said, I'm definately interested in working with what's
already out there, and there is a lot of space where the two
specs overlap.
Rather than trying to explain the project further, I think I'll
just post a link to it. I'll post an announcement in a seperate
email.
Eric
|
