RE: Using Rigid RDF for BLD's XML Syntax

Guys,

We are of the opinion that this proposal adds an RDF dependency but does not bring sufficient value by utilising actual RDF strengths to make this addition count. Any dependency in this standardisation effort should be considered very carefully as it may prevent potential users from adopting the standard and it looks like this dependency is an artificial and unnecessary late addition.

Alex Kozlenkov

W3C AC Representative

Advanced Technology Group

Office: +44 (0)20 8834 6854
Yahoo! Messenger: alex.kozlenkov

Betfair Limited | Winslow Road | Hammersmith Embankment | London | W6 9HP
Company No. 5140986
 
The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company.



-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] On Behalf Of Sandro Hawke
Sent: 14 May 2008 14:27
To: Gary Hallmark
Cc: public-rif-wg@w3.org
Subject: 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
> >
> >   


________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from 
MessageLabs to scan all Incoming and Outgoing mail for viruses.

________________________________________________________________________

Received on Wednesday, 14 May 2008 14:10:36 UTC