Re: discussion of metadata proposals

Michael Kifer wrote:

> Problems with the earlier proposal
> 
>   1. The old proposal injects new syntax at the metadata level,
>      which cannot be processed by BLD rules.
> 
>      For some in this group it is thus a non-starter.

Who?

The ability to process rule metadata with rules is a nice extra but has 
not previously been a requirement. Seems a bit late in the day to add it 
now.

I would have thought that the ability to manipulate the rules with other 
rules was even more useful, why pick metadata as the "non-starter"?

>      In fact, Sandro mentioned that he would like to import just the
>      metadata -- presumably for processing by a ruleset -- and we agree
>      that this is a good application.

Again a nice extra, not a requirement.

>   2. Inability to attach metadata to a subset of rules.
> 
>      The new proposal allows arbitrary nesting of metadata attachments at
>      the level of rules and facts.
> 
>      For instance, Bob may publish a bunch of rules. One subset of those
>      rules he got from Mary and one from Liz, so the subsets are annotated
>      with
> 
>      "http://mary.com/rules"^^rif:iri[date->"2002-12-12"^^xsd:date,
> 				      author->"Mary Smith"^^xsd:string].
>      and
>      "http://liz.com/rules"^^rif:iri[date->"2008-10-10"^^xsd:date,
> 				     author->"Liz Biz"^^xsd:string].
>      respectively.

So long as we can attach metadata to individual rules then this use case 
is sorted. Storing the author information once against a group of rules 
instead of for each individual rule seems like a minor optimization.
I agree it's nice but the base case is annotating a single rule.

>   3. Two separate tags for attaching metadata instead of one.
>      (This is a lesser issue.)
> 
> 
> Responses to the arguments against the new proposal
> 
>   1. The syntax of frames in XML is more verbose than lists
> 
>      The group has decided on using a fully-striped syntax even inside
>      slots, which can make document content quite verbose. Complaining
>      about one extra tag, <meta>, to connect to <Frame> metadata (which
>      will be a much smaller part of the document) is inconsistent with
>      the earlier decisions.

This is a group of individuals, it is bound to be inconsistent :-) We 
are balancing uniformity of syntax with a desire to not make it "too" 
verbose with different people having different notions of how verbose is 
unacceptable.

>   2. The name <Ruleset> for denoting metadata attachment may be confusing.
> 
>      Well, we could perhaps change the name to <Rules>. This latter
>      keyword carries less baggage.

In the overwhelmingly common default cause where each rule has metadata 
then each rule will be wrapped in a <Ruleset> or <Rules> element, that 
just seems less intuitive than wrapping each in something like say <Rule>.

>   3. The new proposal increases the level of nesting of wrappers for
>      attaching metadata.
> 
>      Not true. The nesting level of the wrappers is exactly the same
>      (or smaller, in the absence of single-rule metadata).

>   4. The new proposal claims that it uses fewer tags, but this is only
>      for the metadata markup. We still need another tag to indicate the
>      beginning and end of a ruleset.
> 
>      There is no need for another top-level tag. We can keep the same
>      Ruleset (or Rules) tag at the top. And above that, there will be only
>      rif:Document.

No. We also need a notion of RuleSet separate from this metadata 
grouping. The FLD spec describes the scope of rif:local as "sets of 
formulas". There has to be some syntactic construct in RIF which 
corresponds to this scoping, that was previously RuleSet.
Unless you mean that to be rif:Document?

>   5. If we use RIF syntax for metadata then people will be confused that
>      the metadata is part of the knowledge base.
> 
>      a. This is not a serious argument. People who would be confused
>         by that should not be allowed within 1000 feet of RIF. :-)

I think that comment referred to the readability of the XML and thus the 
chance of making mistakes rather that the intellectual capacity to 
understand there is a difference.

>      b. The main idea of our proposal IS to make metadata into a
>      	  knowledge base and make it processable by other knowledge bases.
> 	  It is just that the metadata is part of a knowledge base that is
>      	  distinct from the main rulebase (cf. Sandro's wish-list).

That is nice, not critical but nice.

>      c. Another advantage is that we can reuse the existing mapping of
>         frames to RDF (in the appendix to the RDF compatibility document).

Sure, a nice feature.

> Explaining misconceptions
> 
>    1. The Ruleset (or Rules) scope has implications for local RIF symbols.
> 
>       The Rules/Ruleset wrappers are just attachment points for metadata.
>       If anything, they are like the include statements of C, not like
>       import statements (see
>       http://lists.w3.org/Archives/Public/public-rif-wg/2008Apr/0006.html)

Previously RuleSet was the scope of rif:local.

>       The local/global symbols business should be left to the import (and
>       future modules) mechanism.
> 
>    2. Where is the global IRI?
> 
>       It is the object Id of the frame used for the metadata. In the above
>       example of Mary's rules,
>       "http://mary.com/rules"^^rif:iri[date->"2002-12-12"^^xsd:date,
> 				       author->"Mary Smith"^^xsd:string],
>       this global Id is "http://mary.com/rules"^^rif:iri.
>       (We are not sure whether the right constant to use is
>        "http://mary.com/rules"^^rif:iri or
>        "http://mary.com/rules"^^xsd:anyURI,
>        but this is beside the point.)

The former.

>    3. Can metadata contain just an Id (the global iri)?
>       
>       Yes:  "http://mary.com/rules"^^rif:iri[]
> 
>    4. Can there be metadata without a global Id?
> 
>       Although the old proposal allowed that, it is unclear whether this is
>       really needed. 

I think it is. A common case will be that rules just have a simple 
comment, having to give each an IRI, especially with our staggeringly 
verbose syntax just for that is not ideal, not a show-stopper though.

> Assuming it is, there are several options:
> 
>       a. Use a local symbol as the object Id in the frame:
>            "someruleset123"^^rif:local[...]

No different from having to give it a URI but less useful.

>       b. Use a variable
>            ?V[...]

Confusing, but possible.

>       c. Use a Skolem constant (we do not have them, but should).

Plausible, if we had them.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Wednesday, 2 April 2008 10:37:00 UTC