Re: Using Rigid RDF for BLD's XML Syntax

I think using Rigid RDF makes a lot of sense.  When someone asks, "how 
in the world did the WG come up with that XML syntax?", I would like to 
simply say "we started with the EBNF and mapped it to standard RDF/XML. 
This makes the syntax machine-processable using a wide variety of 
standard web and semantic web tools."

This "positioning" sidesteps all the issues of striping, attributes vs. 
child elements, etc.  I think that is a good thing.

Sandro Hawke wrote:
> 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:
>
>          <Var>Buyer</Var>
>
>    it would be:
>
>          <Var><name>Buyer</name></Var>
>
>    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:
>   
>         <Const>
>            <rdf:value rdf:datatype="&xsd:dateTime">2007-11-23</rdf:value>
>         </Const>
>
>    [ 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:
>
>         <formula>
>            <Atom>
>              <op><Const ... /></op>
>              <arg><Var> ... </Var></arg>
>              <arg><Var> ... </Var></arg>
>              <arg><Const .../></arg>
>            </Atom>
>         </formula>
>
>    it would be: 
>
>         <formula>
>            <Atom>
>              <op><Const ... /></op>
>              <args rdf:parseType="Collection">
> 	       <Var> ... </Var>
>                <Var> ... </Var>
>                <Const .../>
>              </args>
>            </Atom>
>         </formula>
>  
> 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
> validation.
>
> 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
>      RDF 
>
>    * 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
>
> [1] http://www.w3.org/2005/rules/wg/wiki/F2F7
> [2] http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax
>
>

Received on Monday, 12 May 2008 19:40:16 UTC