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.

Anyone else?

Anything else I can do to help clarify this issue?  It affects metadata
and extensibility, at least, so I'd like to know how seriously we're
pursuing this.

     -- Sandro

> 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 Wednesday, 14 May 2008 13:27:57 UTC