- From: Hassan Aït-Kaci <hak@ilog.com>
- Date: Wed, 14 May 2008 07:33:28 -0700
- To: Sandro Hawke <sandro@w3.org>
- CC: Gary Hallmark <gary.hallmark@oracle.com>, public-rif-wg@w3.org
Sandro Hawke wrote: >> 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? I prefer your proposal to the style used by Harold. But see below. > 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"/> Why not: <Variable name="Buyer"/> - i.e., use the FULL English word. I also prefer using an attribute to record things as names of variables, identifiers, etc., .... -e.g., no need to double-wrap. >>> [ 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 looks heavy - but for the sake of compatibility, why not? Although, (again!), I prefer 'Constant' to '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. Same comment as above, plus: who/what determines the value of such attributes as xml:lang="fr", and how? I mean, where does it come from since not from the syntax nor 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 myself would prefer: <formula kind="atom"> <op><Constant ...>...</Constant></op> <args rdf:parsType="Collection"> <Variable name="..."/> ... <Variable name="..."/> </args> </formula> As I said before, I'd be willing to accept 'op' and 'arg(s)' as opposed my preference; viz., 'operator' and 'argument(s)'. >>> 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 Not too much if we trim it according to my suggestions above. >>> * the elements from the RDF namespace can be confusing, even >>> off-putting (especially to people who are allergic to RDF) That's a point... But then again, I am allergic to XML and look at me: I'm still alive! ;-) >>> * 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 Is it? I thought finalizing the sort of XML vocabulary to be used for RIF was *the* topic to settle at F2F10... >>> So, I think that's the picture, more or less. >>> >>> -- Sandro The above is my (CDN) $.02 ... -hak >>> [1] http://www.w3.org/2005/rules/wg/wiki/F2F7 >>> [2] http://www.w3.org/2005/rules/wg/wiki/Arch/XML_Syntax >>> >>> > > > -- Hassan Aït-Kaci * ILOG, Inc. - Product Division R&D http://koala.ilog.fr/wiki/bin/view/Main/HassanAitKaci
Received on Wednesday, 14 May 2008 14:34:31 UTC