Re: where to hang the metadata? (compromise proposal)

>  > 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.

Received on Friday, 25 April 2008 14:46:44 UTC