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

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:14:44 UTC