W3C home > Mailing lists > Public > public-rif-wg@w3.org > March 2008

RE: (rif xml syntax issue) slots not striped

From: Boley, Harold <Harold.Boley@nrc-cnrc.gc.ca>
Date: Tue, 25 Mar 2008 10:59:43 -0400
Message-ID: <E4D07AB09F5F044299333C8D0FEB45E904FFDEA8@nrccenexb1.nrc.ca>
To: "Sandro Hawke" <sandro@w3.org>, <public-rif-wg@w3.org>

Also RE: RIF Agenda for 25 March

> 6.  Striping in the XML syntax -- Progress Check
>
>     Last week Sandro claimed the XML syntax around <slot> was not
>     fully striped.  Harold disagreed.  Jos wanted a more terse XML
>     syntax.  There was a strawpoll supporting fully-striped syntax,
>     but no exact definition of what that was. 

Maybe it's instructive to give graphs ("object models") for
some of these options.

The current serialization

    <Frame>
      <object>inst</object>
      <slot>key1 filler1</slot>
       . . .
      <slot>keyn fillern</slot>
    </Frame>

uses (primary) system roles and (secondary) user roles.

It can be regarded as representing a graph where system roles
such as 'object' and 'slot' are written into arcs to indicate
the primary arc labels. For the 'slot' (meta)role, user roles
'key1', ..., 'keyn' are written onto the arcs to indicate the
secondary arc labels:

Frame -object-> inst
|   |
|...|key1
|   |
|    -slot-> filler1
|
|     . . .
|
|keyn
|
 -----slot-> fillern

Perhaps RDF tools can be easily extended to parse such
direct user-level slots.

Otherwise, a version of Solution 3 could be considered,
for indirect ("reified") user-level slots:

    <Frame>
      <object>inst</object>
      <slot>
        <Prop>
          <key>key1</key>
          <val>filler1</val>
        </Prop>
      </slot>
       . . .
      <slot>
        <Prop>
          <key>keyn</key>
          <val>fillern</val>
        </Prop>
      </slot>
    </Frame>

Its graph:

Frame -object-> inst
|   |
|...|
|   |
|    -slot-> Prop -key-> key1
|              |
|               ---val-> filler1
|
|     . . .
|
 -----slot-> Prop -key-> keyn
               |
                ---val-> fillern
 
-- Harold


-----Original Message-----
From: Boley, Harold 
Sent: March 12, 2008 11:12 AM
To: 'Sandro Hawke'; public-rif-wg@w3.org
Subject: RE: (rif xml syntax issue) slots not striped

The syntax of BLD is striped on the level of predefined tags such as in

  <And>
    <formula>
      <Exists>
        <declare>
          <Var>Buyer</Var>
. . .

It also allows striping on the level of
user-defined terms such as in

  <Uniterm>
    <op><Const>book</Const></op>
    <slot>
      <Const>author</Const>
      <Uniterm>
        <op><Const>name</Const></op>
        <slot><Const>first</Const><Const>John</Const></slot>
        <slot><Const>last</Const><Const>Smith</Const></slot>
. . .

The syntax for each user-level slot is an explicit key-filler pair

<slot>key filler</slot>

where both key and filler can be general terms.

-- Harold


-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Sandro Hawke
Sent: March 12, 2008 10:17 AM
To: public-rif-wg@w3.org
Subject: (rif xml syntax issue) slots not striped



There's an odd complication in the XML syntax, which I want to point out
and would like to see addressed at some point.

The current BLD gives us bits of XML like this:

    <Uniterm>
      <op>predfunc</op>
      <slot>key1 filler1</slot>
       . . .
      <slot>keyn fillern</slot>
    </Uniterm>
    
and
    
    <Frame>
      <object>inst</object>
      <slot>key1 filler1</slot>
       . . .
      <slot>keyn fillern</slot>
    </Frame>

These are not fully striped.  What class of object is contained in the
<slot> element?  It's some kind of implicit pair or array.

To some extent, this complicates implementation, and leaves the object
model underspecified.  It's not a huge complication if these are the
only two, but still, it's something that every parser and serializer and
some fallback transforms will have to special-case.

== Solution 1 : Stop Being Fully-Striped ==

It would clean up the syntax in some ways.  We could change positional
uniterms from :

    <Uniterm>
      <op>predfunc</op>
      <arg>argument1</arg>
       . . .
      <arg> argumentn</arg>
    </Uniterm>

to 

    <PositionalUniterm>
      predfunc
      argument1
       . . .
      argumentn
    </PositionalUniterm>

Maybe someone should propose an XML syntax for RIF designed for human
readability, if we're going down that road.  If so, the
Presentation-XML-Syntax mapping table will really need the 3rd
object-model/RDF column.  (Maybe it needs it now.)

== Solution 2 : Don't have "slots" be entities or relationships ==

(Similar to what Christian has in PRD)

    <Frame>
      <object>inst</object>
      <key>key1</key>
      ...
      <key>keyn</key>
      <value>filler1</value>
      ...
      <value>fillern</value>
    </Frame>

They might also be interleaved, but that's harder to handle with
schema.   In either case, schema can't enforce the pairing, but it's
pretty obvious if you say each key corresponds to a filler in the same
position in the sequence.

== Solution 3 ==

Make slots explicit and fully-striped:

    <Frame>
      <object>inst</object>
      <slot>
          <Pair>
              <key>key1</key>
              <value>filler1</value>
          </Pair>
      </slot>
       . . .
    </Frame>

Tedious, but straightforward/obvious.

================================================================

    -- Sandro
Received on Tuesday, 25 March 2008 15:00:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:47 GMT