- From: Boley, Harold <Harold.Boley@nrc-cnrc.gc.ca>
- Date: Tue, 25 Mar 2008 10:59:43 -0400
- 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 UTC