Re: Using Rigid RDF for BLD's XML Syntax

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