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

Michael Kifer wrote:
> Dave, there are several possibilities.
> First, values in the frames can be terms with named arguments, which solves
> your problem, I believe.

How? There is no RDF mapping to such terms and the semantics of those 
make such a mapping ... unlikely.

> Second, we actually talked in a previous telecon that more complex formulas
> could also be allowed as metadata.

I missed that in the minutes (I know I've missed a few telecons of 
late). Is there a proposal for the details of that?

Dave

> 
> 
> 	--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:33:59 UTC