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.

We did not restrict the form, but it could be foo(object->o,subject->v), where
foo is the name of the property name.

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

We though that conjunctions might be useful.
Do not know if more general formulas could be useful as metadata.


	--michael  


> 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 18:35:22 UTC