OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How could RDDL be distributed ?

On Wed, Jan 17, 2001 at 05:09:21PM -0500, Jonathan Borden wrote:
> Michael Mealling wrote:
> > On Tue, Jan 16, 2001 at 04:53:06PM +0000, Miles Sabin wrote:
> > > We have a very specific
> > > looming issue (that's my hunch anyway) of large chunks of web
> > > infrastructure depending (perhaps unwisely) on being able to
> > > retrieve resources on the ends of particular well-known URIs on
> > > a regular basis ... a lot of them hosted by the W3C, a lot of
> > > them hosted elsewhere. I predict server meltdown.
> >
> > Yep....
> >
> >
> > > That's my justification for a new protocol. But I think that
> > > there's also a very close connection with some of the areas we've
> > > been discussing here wrt, RDDL and xmlcatalog. Both allow for
> > > local overriding via what is to all intents and purposes a
> > > local cache. I suggest we at least look at whether there's
> > > enough similarity between the two scenarios to make it worth
> > > coming up with a uniform solution.
> >
> > Yep....
> >
> Perhaps we can say that xmlcat allows for local overriding of how URIs
> supplied as namespace names and via RDDL documents are dereferenced. RDDL
> alone makes no mention of exactly how or how ought a URI be dereferenced.
> Presumably a RDDL document might contain information useful to a RESCAP or
> DDDS http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-02.txt
> server. Could you clarify the relationship between these two as you envision
> things?

RDDL/xmlcat/etc are data sources for a RESCAP. I'll run through 
a scenario:

Let's say I'm doing some RDF stuff and I come across some URI in
an arc that I'm not familiar with but I need some information about
how it relates to RDF in order to keep processing. I take that
URI and attempt to find some information about it. I first
hand it to my contextualization service to find out if my local
XML expert system knows anything about it. It returns nothing so 
apparently I don't have some localized concepts about it. 

I then use the DDDS based URI Resolution process to find a service
out there that can answer the question I'm after. That process
comes back and tells me that there is a server running the RESCAP
protocol that can answer questions authoritatively about that URI.
I send that RESCAP server the following question: "is this thing an
XML Namespace name?". If it answered yes then I can ask it more
questions such as "Do you have a CSS Stylesheet for it?" or "Is
there a XML Schema equivalent available?". The answers to these
question can come from an RDDL blob that was retrieved from some
authoritative location.

> I am slowly reading through what are a large number of articles and RFCs in
> this area (as well as the discussion circa 1995-1996 of Uniform Resource
> Characteristics). Clearly much of this work involves protocols and clearly
> there has been much thought given to these topics.

Oh lord! You're reading some ancient history! ;-) Coming from one
of the original authors that talked about URCs you can take it on good
faith that the likes of RDF and the Dublin Core have long eclipsed 
the thinking around URCs. 

> My thinking regarding RDDL is that RDDL ought stick to being a "language"
> for which to describe URIs and not overstep its bounds into the protocol
> arena. Yet working with protocols, especially protocols designed to resolve
> URIs, is important and this is where RDDL aware software might be useful.

Yes. RDDL provides the information in a well managed, explicit way but
small chunks of it would be reliably used by protocols to answer certain
lightweight, often asked questions...


Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com