W3C home > Mailing lists > Public > www-tag@w3.org > February 2002

[namespaceDocument-8] RDDL wishlist

From: Jonathan Borden <jonathan@openhealth.org>
Date: Thu, 21 Feb 2002 08:14:07 -0500
Message-ID: <028701c1bad9$aacfcfe0$0301a8c0@ne.mediaone.net>
To: "Patrick Stickler" <patrick.stickler@nokia.com>, "TAG" <www-tag@w3.org>
I am forwarding, with permission, an email from Patrick Stickler with some
comments.

Patrick Sticker wrote:
[in response to an email from me]

>
> >> -- take a look at:
> >>
> >> http://www.openhealth.org/talks/Extreme%20RDDL.ppt
> >>
> >> and
> >>
> >> http://www.openhealth.org/talks/What%20is%20a%20namespace.doc
>
> OK. Good ideas in there. I fully agree with the "space"
> view of namespaces, that they simply serve as a scope of
> intersection between disparate resources.
>
> And I don't by any means miss the great benefit of RDDL
> providing for both human and machine readable information.
>
> To get really practical, here's my wishlist, then for a
> RDDL based solution:
>
> --
>
> 1. I want to be able to use any URI whatsoever to name each
> RDDL resource. Not an ID. Not an http: href/URL. Any URI.
> Something equivalent to rdf:about.

This is an interesting question: should a namespace document be able to make
statements about URIs not within the namespace? The reason _for_ being able
to do this, is that the namespace being described might not be the base URI
of the document. I had initially thought that allowing _xml:base_ (which
RDDL does) would allow correct composition of an arbitrary URI with the ID
of the rddl:resource (note the ID is optional), to serve as the source URI
in the XLink. I am not sure if this works. One could modify the syntax to
allow either an ID or about attribute if this is something desirable.

>
> 2. I want to be able to specify multiple locations from which
> any given resource can be retrieved, such as local, intranet,
> and internet locations (fallbacks, etc.)

One can already do this. The xlink:role and arcrole can remain constant with
various xlink:hrefs.

>
> 3. I want to be able to embed arbitrary RDF instances in
> my RDDL instance to provide rich relational knowledge not
> expressible in simple XLinks or too cumbersome to express
> in complex XLinks.

This is largely a syntactic decision. Of note, it is easier to merge Xlinks
into the XHTML syntax because the arcs are defined using attributes in the
XLink namespace.

>
> 4. I want their to be an official (not just suggested)
> transformation from RDDL, with or without embedded RDF to
> just RDF, with any embedded RDF included, so that it is
> absolutely sure that all valid RDDL instances will be
> meaningful to RDF based agents and there no black holes
> or disconnects between RDDL/XLink and how things are
> usually modelled in RDF.

I agree that the translation between XLink and RDF should be made
'official'.
>
> --
>
> If I could have all of the above, then I would be fairly happy
> with RDDL and would support its adoption as an official
> (interim) solution for dynamic retrieval of architectural
> components by applications (and general dissemination of
> information to humans).
>
> I would use the XHTML vocabulary to provide information to
> humans.
>
> I would use the RDDL/XLink vocabulary to provide the equivalent
> functionality as the venerable SGML Catalog -- i.e. name to
> location mapping.
>
> I would use RDF for everything else (or actually, I'd use
> RDF for everything, but at least the XLink catalog functionality
> would be useful for XML-only applications... ;-)
>
> I think that #2 and #3 are already doable, though may need
> clarification/tweaking. #1 looks like a non-trivial change.
> #4 is helped by the fact that RDF/XML can be embedded in
> any well formed XML instance, though there are likely RDDL
> and XHTML schema/validation issues there.
>
> What do you think?
>

I think #4 is fairly straightforward.(RDDL is really just XHTML + XLink with
a little sauce)

The issue is how many extensions to put into RDDL 2 (or whatever it will be
called) ? I am not opposed to #1 if there are no objections.

Jonathan
Received on Thursday, 21 February 2002 07:48:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:04 GMT