Re: ISSUE-51: Another possible compromise for metadata syntax

Dave, there are several possibilities.
First, values in the frames can be terms with named arguments, which solves
your problem, I believe.
Second, we actually talked in a previous telecon that more complex formulas
could also be allowed as metadata.


	--michael  

> 
> As mentioned in last week's call ... orthogonal to the issue of where 
> the metadata can go is the question of what metadata can be expressed.
> 
> My starting point is that the metadata should be mappable to RDF since 
> that is the metadata standard for the semantic web.
> 
> In Jos' original proposal metadata values were expressed in an 
> RDF-compatible way using an N3/Turtle like notation. This had the 
> disadvantage that a separate RDF mapping needed to be specified but the 
> advantage that structured metadata values are possible, indeed easy to 
> express.
> 
> In particular, I would like to be able do things like use the FOAF 
> vocabulary to describe a rule author. This requires the ability to have 
> structured values ideally including blank nodes. Jos' proposal handled 
> this fine.
> 
> In the current BLD proposal metadata is restricted to Frames, one per 
> Rule/Group. This has the converse advantages/disadvantages - the RDF 
> mapping is already defined but there is no ability to express structured 
> values other than via Uniterms.
> 
> To address this issue would it be appropriate to either (a) define a 
> notion of nested Frames or (b) allow multiple Frames within the metadata 
> block which can then use explicit Consts to link from one frame to a 
> related frame?
> 
> Dave
> -- 
> Hewlett-Packard Limited
> Registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England
> 
> Chris Welty wrote:
> > 
> > 
> > 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.
> >>
> >>
> > 
> 
> 
>

Received on Monday, 28 April 2008 17:29:13 UTC