W3C home > Mailing lists > Public > www-rdf-interest@w3.org > November 2003


From: Adam Souzis <adam-l@souzis.com>
Date: Tue, 04 Nov 2003 09:40:28 -0800
Message-ID: <3FA7E48C.9050507@souzis.com>
To: Graham Klyne <GK@ninebynine.org>, www-rdf-interest@w3.org

Thanks for your feedback, responses below.
-- adam

Graham Klyne wrote:

> At 00:33 03/11/03 -0800, Adam Souzis wrote:
>> Rx4RDF provides a deterministic mapping between the RDF abstract 
>> syntax to the XPath data model,  allowing you to query, transform and 
>> update a RDF model with languages syntactically indentical to XPath, 
>> XSLT and XUpdate (which we call  RxPath 
>> <http://rx4rdf.liminalzone.org/RxPath>, RxSLT 
>> <http://rx4rdf.liminalzone.org/RxSLT>, and RxUpdate 
>> <http://rx4rdf.liminalzone.org/RxUpdate>, respectively).
>> A reference implementation (in Python) and formal specification can 
>> be found at http://rx4rdf.liminalzone.org/
> I'm taking a quick look at the RxPath spec [1], and have a question:
> [1] http://rx4rdf.liminalzone.org/RxPathSpec
> Do you really mean the Subject Elements to include all graph nodes 
> that appear as objects of any statement?  The spec says so, but the 
> naming seems at odds with this.

Yes, that's what I mean: "/*" to selects all the resources in a model -- 
if a resource is not the subject of any statements it will have no 
children (Predicate Elements).  So I can see the name "Subject Element" 
as a bit confusing -- the name is describing its position in the tree.  
Calling them "Resource Elements" seemed too general but maybe that's better.

> Some other comments:
> I'm a little concerned by (what seems to me) the indecisive treatment 
> of loops in an RDF graph.  I think having a distinction between 
> "circularity-checked" and "circularity-unchecked" *in the data model* 
> is confusing.  My inclination would be to let the data model contain 
> infinite trees (ala "circularity-unchecked"), and provide for a finite 
> traversal of the nodes as an *operational mode* of an RxPath 
> processor.  In practical terms, this shouldn't be very different from 
> what I imagine you do now, but it feels more soundly based to me.

Good point -- yes, this what I intended.  I think i do call them 
"modes", but this section should be moved out of the data model section 
of the spec.

> ...
> At first glance, I like your XML serialization for RDF, particularly 
> when coupled with the RhizML syntax.  Maybe we don't really need a new 
> syntax for RDF right now, but this does seem to capture a nice balance 
> of directness w.r.t. the RDF model, and simplicity.
> ...
> Do you have any plans for an "RxForms" module?  I.e. some way of 
> allowing new information to be entered into defined structures 
> (including definition of new structures).  A simple example 
> application would be something like foaf-a-matic [2].  (I was working 
> on something like this a while ago, but that's rather fizzled out for 
> now as I got distracted by other things, but it's something I'd like 
> to revisit.)
> [2] http://www.ldodds.com/foaf/foaf-a-matic.html

I'm having a bit trouble visualizing this. If you look at the form pages 
in Rhizome, they're RxSLT pages to generate the form and the post 
handlers are RxUpdate pages that update the model. If you want to create 
entirely new structures you can edit the resources directly using RxML.  
Given this, how would a "RxForms" fit in?

> ...
> Can Rhizome use different RDF stores for its back-end?  (I'm thinking 
> of Jena, which I know can be called directly from Python, using 
> Jython.  Or maybe a Joseki module in Python?)
Rhizome relies on Rx4Rdf as its RDF API (i.e. it only access RDF through 
RxPath or Rx4RDF DOM, etc.) so the question is could the Rx4RDF 
implementation use different RDF stores? I hadn't thought much about 
that -- right now it wouldn't be so hard but that just because the 
implementation is so simple minded, a more efficient one  would be 
harder to generalize the RDF backend.

> ..
> Overall, based on a quick scan, I think this looks like rather nice work.
> #g
> ------------
> Graham Klyne
> For email:
> http://www.ninebynine.org/#Contact
Received on Tuesday, 4 November 2003 12:40:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:45 UTC