- From: Jonathan Borden <jonathan@openhealth.org>
- Date: Thu, 21 Feb 2002 08:14:07 -0500
- 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 UTC