Using Rigid RDF for BLD's XML Syntax

At F2F7 in September [1], we went through a list of XML Syntax issues
[2] which resulted in the general shape of the current BLD XML syntax.
In particular, we decided for that Working Draft to use a fully-striped
XML exchange syntax, but it would NOT be RDF/XML.  (Specifically, we
were talking about using a constrained subset of RDF/XML which can be
validated by XML schema processors. I've heard this called "rigid RDF"
and have started using that term, myself.)

So this language we now have is a sort of a compromise.  It's more
explicit/verbose than we might have (Jos and Hassan have been pushing
for more brevity), but it's less explicit/verbose than rigid RDF.

Personally, these days, I'm really okay with any of these three options.
I see lots of trade-offs, and I don't have enough foresight to know
what's going to be best.  After my pitch for rigid RDF last year, when
no one else seemed very interested, I let go of it.  But now Christian
tells me he's hearing some people pushing in that direction again, and
asked me how close we were.

So, here are the differences, I think, between the current BLD XML
syntax and a reasonable rigid RDF syntax for BLD. 

1.  Add a "name" role inside "Var" (for full striping)

   Instead of:


   it would be:


   or perhaps:

         <Var name="Buyer"/>

   [ It seems silly, I know.  If there were metadata about a variable
   occurance it would start to make more sense. ]

2. A new role inside "Const" (for full striping)

   Instead of:

        <Const type="&xsd;dateTime">2007-11-23</Const>

   it would be:
           <rdf:value rdf:datatype="&xsd:dateTime">2007-11-23</rdf:value>

   [ It doesn't have to be "rdf:value", we could use "rif:value". ]

3. The rif:iri and rif:text datatypes handled as special cases, since
   RDF has special constructs for these:

   Instead of:

       <Const type="&rif;iri">&cpt;purchase</Const>

   it would be:

       <Const><rdf:value rdf:resource="&cpt;purchase" /></Const>

   And, instead of:

       <Const type="&rif;text">chat@fr</Const>

   it would be:

       <Const><rdf:value xml:lang="fr">chat</rdf:value><Const>

   Again, this is just in the XML serialization; it doesn't change the
   presentation syntax or the semantics.

4. In Atom and Expr, where the <arg> role is repeated (with order
   being significant), we would instead have a single <arg> role and
   its value would be an rdf:List of the arguments.

   Instead of:

             <op><Const ... /></op>
             <arg><Var> ... </Var></arg>
             <arg><Var> ... </Var></arg>
             <arg><Const .../></arg>

   it would be: 

             <op><Const ... /></op>
             <args rdf:parseType="Collection">
	       <Var> ... </Var>
               <Var> ... </Var>
               <Const .../>
I think that's it, but I haven't done a line by line examination of
the syntax, so I may have missed something.  I should say, also, I
think we'd probably want to use a rigid RDF where the child elements
are required to be in lexicographic order, so it would really be
<Atom><args ...><op ...></Atom>, which is kind of annoying, but allows
one to use a general-purpose serializer and still have schema

Some advantages of using this kind of rigid RDF for RIF:

   * it allows some synergy between RDF tools and RIF: even easier
     de-serializing of RIF; storing RIF in triplestores; examining RIF
     with RDF browsers, etc.

   * it may help settle the Metadata question

   * it makes the syntax straightforward and clear to people who know

   * it specifies how RIF documents map to objects and/or RIF frames
     (for applications using syntax reflection)
   * it allows fallback processing rules to be writtin in RIF instead of
     XSLT (probably Core plus some "rewrite rules" extension)

Some disadvantages:

   * it makes the XML syntax even more verbose

   * the elements from the RDF namespace can be confusing, even
     off-putting (especially to people who are allergic to RDF)

   * it prevents us from making arbitrary (non-striped) XML constructs
     that might be useful and elegant.

   * it's a course change, late in the day

So, I think that's the picture, more or less.

       -- Sandro


Received on Monday, 12 May 2008 16:16:05 UTC