ISSUE-51: Another possible compromise for metadata syntax

Here's another hopefully intermediate/compromise proposal for the meta data.

The current BLD draft shows:

   Document  ::= 'Document' '(' IRIMETA? DIRECTIVE* Group? ')'
   Group     ::= 'Group' IRIMETA? '(' (RULE | Group)* ')'

I suggest something like:

   Document  ::= 'Document' '(' IRIMETA? DIRECTIVE* (Group | Rule)* ')'
   Group     ::= 'Group' IRIMETA? '(' (RULE | Group)* ')'
   Rule      ::= 'Rule' IRIMETA? '(' RULE ')'

This basically tries to address both Jos (et al) and Michael (et al) conflicting 
concerns.  If you don't want to use Group, you don't have to, if you don't want 
to use Rule, you don't have to.  I think this proposed syntax allows us to keep 
these names, avoids having to nest the Rule inside the group, and also for 
future extensibility to e.g. FOL you can just drop the Rule part and extend 
through Group.

It makes the grammar a little more verbose, but the actual syntax of rules and 
rulesets is no more verbose that either current proposal.

Also, *as a different point*, if we keep this I would suggest modifiying the 
Group production so that you don't have to type 'Group' for every repeated rule 
within a group, something like:

   Group     ::= 'Group' IRIMETA? '(' (RULE* | Group)* ')'


-Chris


Sandro Hawke wrote:
>>  > Thinking over today's difficult discussion about metadata, it seems to
>>> me that the right solution is this:
>>>
>>>    1.  Allow metadata, syntactically, on every object, by way of a
>>>        <meta> child element which is legal on every capitalized (class)
>>>        element.  No need for wrapper elements.  In a normal rule, the
>>>        "Forall" is where you'd hang the metadata.  I have some ideas for
>>>        the PS, but no favorites.
>>>
>>>    2.  Add a "group" element, for making these conceptual groupings that
>>>        Michael speaks of (and I'm familiar with from my own rule
>>>        programming), where the metadata applies to a set of a few
>>>        rules).
>>>
>>> What about this approach would be so bad?
>> For me the question was not how to attach metadata, but rather whether 
>> and how to identify rules.
> 
> It sounds like the question is about how people conceptualize the
> structure and elements of their rulesets.  When programming, if you put
> a comment block above some code, which code does it apply to?  It's
> mostly the blank lines and comment characters (eg big horizontal lines)
> that answer this, in my code (although it depends on the language, a
> bit).
> 
> So, it seems like we should allow:
> 
>    <Document>
>       <Group>
>         <Group>
>            ...
>              <Rule>
>                 <Forall, etc>
> 
> where Group and Rule are optional.  Metadata, including URIs, go on the
> Document, Group, and Rule elements.   (I'm skipping the rule stripes,
> for brevity here.)
> 
> This has no formal semantics in BLD, of course.  It's for humans and
> rule management, like other non-semantic metadata.  Writing translators,
> you can ignore these tags, unless your rule language has some
> similar/equivalent structure.  Maybe you even translate them to/from
> blank lines.  [ half joking - the point is that it wouldn't be wrong. ]
> 
> If people start to want semantic metadata (rule priorities?), this
> probably adapts to that just fine, too -- it's obviously general -- but
> we can't worry about that too much, with only a month to go on BLD.
> 
> Similarly, some seem to see the asymmetry between Group and Rule as
> reflecting real concepts, while some see Rules as silly, some see Groups
> as silly, ... etc.  I don't think it's a huge burden to have both.  Some
> people want one, some want the other, some want both -- let's just have
> both.  Can we live with that?
>  
>      -- Sandro
> 
>> For a long time our top-level element in RIF was the ruleset and the 
>> second-level element was the rule.
>>
>> Recently the notion of "group" was introduced, which lies between the 
>> ruleset and the rule: a ruleset contains groups and groups contain rules.
>> So, we have:
>>
>> Ruleset
>>     |
>>   Group
>>     |
>>   Rule
>>
>> I myself do not really see the need for this group element in BLD, but I 
>> do not strongly object to it.
>>
>> The current draft of BLD allows identifying rule sets and groups, but 
>> not rules.  I was arguing that it should be possible to identify rules.
> 
> 

-- 
Dr. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
http://www.research.ibm.com/people/w/welty

Received on Friday, 25 April 2008 19:08:35 UTC