<PaulVincent> scribenick PaulVincent

<PaulVincent> Christian: will decide today on breakout topics eg implementation...

Extensibility

<PaulVincent> Chris: session on Extensibility

<PaulVincent> scribenick: PaulVincent

Reviewing Sandro's Extensibility_Design_Choices doc (all definitions quoted in the minutes below are from this document)

http://www.w3.org/2005/rules/wg/wiki/Arch/Extensibility_Design_Choices

Definitions: what is a RIF Document?
"A RIF Document is an XML document with a root element called "Document" in the RIF namespace (http://www.w3.org/2007/rif#). In general, RIF documents are expected to convey machine-processible rules, data for use with rules, and metadata about rules."

Paul: does this imply all data in a RIF doc?

Sandro: no

Jos: RIF doc may not be XML?

Sandro: that is the current intent: RIF is an XML doc

Christian: RIF may not contain data for use in rules
... withdraws comment

<sandro> PROPOSED: accept definition of RIF Document as in http://www.w3.org/2005/rules/wg/wiki/Arch/Extensibility_Design_Choices?action=recall&rev=35

Chris: proposes RIF Document definition is set once here as normative

Christian: if this is a final definition then need more defining eg on data containment

Axel: object to definition on root element as RIF:Document

<Harold> What about: In general, RIF documents are expected to convey machine-processible rules, facts for use with rules, and metadata about rules.

<sandro> PROPOSAL WITHDRAWN

<sandro> Chris: defn okay -- nothing but nit picking complaints

Chris: retracts enforcement of never-adjust-this definition

<sandro> Sandro: I do intend "RIF Document" to imply they are all XML documents

<sandro> Chris: The other issue was data, facts, and making it lower priority (ie at end of list with weasel words)

Harold: would prefer facts rather than data (in RIF doc definition) as knowledge = rules + facts

"A RIF System is anything which might produce or consume a RIF Document. Typical RIF systems include rule authoring tools and rule engines. These systems may consist of a non-RIF subsystem and a RIF translation subsystem; taken as a whole, they form a RIF system."

<sandro> Sandro: Are "RIF Consumer" and "RIF Producer" good?

<sandro> everyone happy

<sandro> re RIF Dialect -- Axel -- Dialect may have more than XML.

"A RIF Dialect is an XML language for RIF Documents. Each RIF Dialect defines semantics for the set of RIF Documents which conform to its syntax definition. Dialects may overlap other dialects; that is, a given document may be an expression in multiple dialects at the same time. "

Axel: objects to RIF Dialect being an XML language

<AxelPolleres> On http://www.w3.org/2005/rules/wg/wiki/AbstractModel I proposed the following notion...

<AxelPolleres> (which is probably also not the last word, but some things might be worthwhile):

<AxelPolleres> # a dialect MUST restricts/define which parts of the abstract model you are allowed to use in its instance rulesets and how.

<AxelPolleres> # a dialect MUST assign a semantics to this restricted part (model-theoretic, proof-theoretic, operational in that order of preference)

<AxelPolleres> # a dialect MAY assign "roundtrippable" own syntaxes (for instance, BLD defines a represenation syntax as well as an XML syntax) and even define the semantics in terms of one of those special syntaxes (for instance BLD's semantics is defined in terms of its representation syntax).

<sandro> Bob: usually assumes you can write syntactically valid programs without them being meaningful.

<sandro> Sandro: I specifically mean to rule that out.

<Harold> What about: A RIF Dialect is a specification of a (usually infinite) set of RIF Documents.

<AxelPolleres> what is missing is probably: # MUST defne an XML Language for RIF Documents

<sandro> Bob: Then syntax must be clear as going MORE DETAILED than in Schema.

<sandro> Gary: cf Signatures....

Christian: dialect is more than a schema
... dialect has a normative specification outside of the schema

<sandro> Axel reads what he put on IRC.

Axel: suggests bullet list for definition

<sandro> Sandro: Let' leave dialect not well defined and move on.

Chris: move onto definition of Language Conflict

"A Language Conflict occurs when multiple dialects specify different meanings for the same document. That is, if there can exist a RIF Document which syntatically conforms to two dialects, and a system can be conformant to one of the dialects without also being conformant to the other, then there is a language conflict between the dialects. "

Harold: can only have inclusion hierarchy: multiple semantics is an issue

Christian: need to define language conflict to know what we need to avoid

<sandro> MK: the def of Lang Conflct doesn't need to go into Spec -- that's for us.

Sandro: this may be a concept for dialect designers

Michael: we should design to avoid this

<sandro> csma: We seem to agree what is a language conflict, and that we don't want them.

Chris: RIF Extension

"A RIF Extension is a set of changes to one dialect (the "base" dialect) which produce another dialect (the "extended" dialect), where the extended dialect is a superset of the base dialect. "

<sandro> Axel: Superset in the sense that every document in the extended dialect is a document in the base dialect.

<sandro> Jos: superset is too restrictive.

<sandro> csma: but that's what extension means.

Jos: removing from "where" to avoid "superset" will be more general

Chris: RIF Profile is the complement of RIF Extension
"A RIF Profile is the complement of a RIF Extension; it is a set of changes to one dialect (the "base" dialect) which produce another dialect (the "profile" dialect), where the profile dialect is a subset of the base dialect."

Sandro: Profile is a general term for a standard subset

Jos: this is already a design choice (Extension and Profile)

<sandro> Jos: These definitions reflect reflect some design choices -- they preclude naming dialects

<sandro> Sandro: true

Jos: removing subset/superset makes extension=profile

Christian: can extend definition to be extension = dialect that covers more rule types than the parent (etc)

<sandro> Sandro: rif change, modification, delta, .....

Chris: ... but extension could also modify definition of ruleset etc

Christian: RIF extension can also process the parent's rules

<sandro> csma: we need to keep in mind that "RIF Extension" as written here is a specifc kind of thing, and there is a more general notion.

Chris: need another term for a delta / derivative that is not an extension / profile

<sandro> "RIF Functionality Extension" vs "RIF Pure Syntactic Superset Extension"

Sandro: RIF syntactic extension and functional extension?

Michael: Also consider an "invisible extension" ... so we need to define the extensions more specifically

Jos: invisible extensions that are just syntactic then this is not a RIF extension

<sandro> Jos: this definition means "invisible extension" is not an extension.

<sandro> Sandro: true.

<sandro> Chris: Maybe metadata doesn't count as part of the syntax....?

Chris: need to define a more general notion of RIF extension
... Backward and Forward Compatibility

"A system is Backward Compatible if it accepts old versions of its input language. All systems are backward compatible for languages which change only by incorporating extensions (that is, by growning). In a large, decentralized system (like the Web), backward compatibility is extremly important because new system will almost certainly have to read old-version data (either old documents, or documents recently written by old software)."

"A system is Forward Compatible if it behaves well when given input in future or unknown languages. In a large, decentralized system (like the Web), if the systems are not all forward compatible, new language versions are extremely difficult to deploy. Systems which are not forward compatible will behave badly when they encounter new-version data, so the users of these systems will tend to push back on the people trying to publish the new-version data. If a large enough fraction of the user base is using such systems, the push back becomes too great and migration to new versions is prevented. In small, controlled environments, the software for all the users can be upgraded at once, but that is not practical on the Web."

<sandro> Chris: I understand BC, but it sounds like there is wiggle room around metadata, eg language identifier....

Sandro: example: IE identifies itself as Mozilla as this was meant to be metadata but is now used as an executable interpretation...

<AxelPolleres> I personally don't really like dialect identifiers... so far, any convincing argument for them?

Sandro: Metadata compatibility is important (Chris: some noncompatible metadata changes may not prevent executable backward compatibility)

Christian: "future or unknown languages" term means?

Sandro: this is simply a problem definition, not a solution

<AxelPolleres> What I wanted to say is that Fwd-compatibility, if desired, already *fixes* the fallback mechanism in some sense.

Chris: Fallback

"A Fallback mechanism provides forward compatibility by defining a transformation by which any RIF document in an unknown (or simply unimplemented) dialect can be converted into a RIF document in an implemented dialect. In many cases, fallback transformations will have to be defined to be lossy (changing the semantics of the document). Fallback mechanisms can be simple, like saying that certain kinds of unrecognized language constructs are to be ignored (as in CSS), or they can be complex, invoking a Turing complete processor (as in XForms-Tiny)."

Sandro: allows for graceful behavior - predictable degradation

Jos: why should fallback imply convergence eg rather than ignore some aspect

<AxelPolleres> examples for Fallback:

<AxelPolleres> - refuse ruleset

<AxelPolleres> - ignore rules

<AxelPolleres> - ignore rule parts

Michael: this is an issue, not a solution

Axel: is "ignore" a transformation?

<AxelPolleres> note there is also "semantic fallbacks" probably. (think of strict vs. loose language layering (in Jos' sense))

Chris: impact

<sandro> Jos: switching from "transformation" to "mapping" helps.

<Harold> Issue: If the receiver just omits what they can't understand, the sender won't know how much was understood. So, the receiver need to inform the sender about what they omitted.

<AdrianP> Define default semantics as a fallback mechanism

Sandro: a single dialect extension may have multiple fallbacks with multiple impacts

"Impact is information about the type and degree of change performed by a fallback transformation. For instance, a fallback transformation which affects performance might be handled differently from one which will cause different results to be produced. This difference is considered impact information. "

<AxelPolleres> Examples of impact might be:

<AxelPolleres> - soundness lost

<AxelPolleres> - completeness lost

<AxelPolleres> ...

Gary: Example - bad element tree being pruned: ie could remove part or all of a rule

<AxelPolleres> sounds kind of like "cautious" and "brave" fallbacks.

<sandro> Gary: prune at AND and you get false negatives; prune at RULE and you get fewer results --- user needs to choose.

Chris: highlights of extensions
... user extensions vs official extensions
"Extensible systems may support User Extensions (Vendor Extensions), Official Extensions or both. A user extension is one which can be defined and widely (and legitimately) deployed without coordinating with a central authority (such as W3C or IANA). Official extensions are those produced under the auspices of the organization which which produced the base dialect (in this case W3C). Some people consider user extensibility to be required for a system to truly be extensible. The RIF Charter extensibility requirement concerns user extensions."

Christian: user extensions for own fancy features via an extension framework - this is a strong motivation for adoption of extensibility

<sandro> csma: Big Goal: to allow users to deploy extensiion which eventually turn into official extensions.

Christian: examples may be vendor extensions, which can then be brought into an official extension

<AxelPolleres> Do we want to go down to how a certificate for endorsement of a dialect needs to look like?

<Harold> How to avoid that a vendor comes up with their fancy 'user' extension to differentiate themselves from other vendors.

Christian: will say 2nd example after the break...

BREAK to 10.35

<Harold> ... We could encourage vendors to collaborate on joint 'usergroup' extensions, so chances would go up for their extensions to become official.

<ChrisW> Scribe: MichaelKifer

discussion of invisible extensions

"An Invisible Extension defines a dialect which has exactly the same syntax as some other dialect but different semantics. This is sometimes desirable when the different semantics are related in a practical and useful way, such as reflecting the different capabilities of competing implementation technologies. Deployment, testing, and the definition of conformance for invisible extensions require out-of-band information, which may be problematic. For example, there is a subset of OWL-Full which has the same syntax as OWL-DL, but which has more entailments (ie different semantics). This subset of OWL-Full is an invisible extension of OWL-DL; its presence (and thus the different intended semantics) cannot be determined by inspection and must be conveyed out-of-band in any applications where the semantic difference might matter."

csma: clarify the diff betw invisible extensions and language conflicts

sandro: invisible extension is a "harmless" language conflict

<sandro> *might* sometimes be harmless.

<sandro> Jos: better example of invisible extension is RDF and OWL-Full. Same syntax, very very different semantics.

<sandro> Sandro: Yes, but.... some caveats maybe.

mk: dont want language conflicts, but the notion of invisible extension is useful for specifying fallbacks and impact factors.

sandro,csma: want to avoid invisible extensions

scribe: as well as language conflicts

<sandro> Chris: There is an intuitive notion of Invisible Extension that makes it different from Language Conflicts in general....

<sandro> Sandro: Yes

<AxelPolleres> How about, "Strictly semantically layered extension" and "loosely layered semantically layered" semantics.

examples of invisible extensions: OWL-DL->OWL-Full, Well-formed, stable negation vs stratified negation

<ChrisW> seemed like general agreement that invisible extensions and language conflicts are the same and undesirable

<Harold> Since XML can express things with elements or attributes, we should use one element, e.g. Naf, with an attribute, e.g. flavor, which could distinguish stable, well-founded, etc.

<sandro> Sandro: An "invisible extension" would be "naf" and you have to say out of band which kind of NAF it is.

<Harold> So, <Naf flavor="stable"> vs. <Naf flavor="well-founded">

<AxelPolleres> ChrisW, they are NOT the same: invisible extensions are a special case of conflict!

<Harold> where one could be picked as the default.

<josb> "An invisible extension defines a dialect which is a superset of the base dialect, but which defines a different semantics for documents in the base dialect."

sandro: motivating example for user-defined extension
... what's the mechanism for granting permissions to define a dialect?

what namespace?

Harold: namespace change is not a problem

<Harold> because it also occurs for RIF's own versions.

csma: if u want to become a standard, use RIF namespace.

sandro: may not know if something will become a standard at the beginning
... another way is to rewrite vendor NS into a RIF NS automatically

<Harold> Developers of user dialects should be strongly encouraged to reuse as many as possible of existing (official) standards when they look for a basis to define their own extension dialects.

sandro: how can we ensure that different groups developing different dialects don't step on each other

<AxelPolleres> +1 we need some "principle of maximum reuse"

csma: pro for having a central authority: there is some quality control

<Harold> Re 2.1.2: What about a much less expensive light-weight control.

sandro: W3C doesn't want to be a central authority for every possible extension. This position has led OASIS to take over some of the extensions.
... of XML

csma: create a RIF Consortium

sandro: central repository of namespaces has a problem in case of IP and patent enforcement attempts

<Harold> Maybe, by analogy to Incubator Groups, W3C needs a notion of 'Outcubator Groups' which maintain further development of specs after a WG ended.

<sandro> csma: we'll have to decide soon whether BLD and PRD use the same namespace

<AxelPolleres> solution: common abstract model, common namespaces for overlapping constructs :-)

csma: how do we manage overlap between dialects? for ex: BLD and PRD are not extensions of each other, but they share the condition sublanguage. What namespace for that sublanguage?

<sandro> sandro: if we think of BLD lists as an extension, is there some reason to put them in a different namespace.

gary: maybe just use the same namespace for everything?

sandro: +1

csma: but how do we achieve this at the technical level?

axel: another way is to split off abstract model and dialects, e.g. CONDITION is an abstract model construct, it is not specific to a dialect

<Harold> The namespace http://www.w3.org/2007/rif# should contain at least http://www.w3.org/2005/rules/wg/wiki/Core/Conditions. A new namespace http://www.w3.org/2007/rif/horn# could be created for http://www.w3.org/2005/rules/wg/wiki/Core/Rules. BLD would then become an extension of Conditions by Horn rules.

<sandro> PROPOSED: RIF-WG will only use its one namespace, but to allow user extension to use other namespaces.

csma: what if the same document is in both dialects (eg, a subset of PRD and BLD)? Then u don't want the same constructs (eg negation) to be in different namespaces.

<sandro> PROPOSED: All official extensions will use the main RIF namespace, but we will support user extensions using other namespaces.

<AxelPolleres> Well, we would be getting close to a Core here again, harold, don' we?

<sandro> PROPOSED: All official extensions will use the main RIF namespace, but we will support user extensions using other namespaces.

<sandro> PROPOSED: All official extensions will use the main RIF namespace, and we will support user extensions using other namespaces.

<sandro> PROPOSED: All official (ie standard) dialects will use the main RIF namespace. We will support user extensions using other namespaces.

<sandro> Harold: what about subspaces?

<sandro> Sandro: No, really the same namespace string.

<AxelPolleres> This fits very well with the common abstract model idea... btw., I like it.

<sandro> RESOLVED: All official (ie standard) dialects will use the main RIF namespace. We will support user extensions using other namespaces.

<sandro> csma: if this leads to serious design difficulties, we may to re-open this, of course.

csma: this resolution may cause design difficulties. if this occurs then we'll dissolve or modify the resolution

<sandro> Do we ever allow invisible extensions? => not really resolved yet

csma/sandro: issue: do we allow invisible extensions?

mk: unclear what "allow" means

<sandro> How do you know when extensions are compatible? => no idea yet.

issue: how do we know if extensions are compatible?

csma: probably we don't care

<sandro> "Do people ever need" .... component library, mk: difficult for 6months times. => No criticial impact here now.

<Harold> An extension should always start from the largest base dialect(s) that will be semantically contained in the newly defined dialect.

issue: should we allow flags at the document root to modify the meaning of syntactic constructs (eg, to say whether negation is a WFS-NAF or ASP-NAF or ...)

sandro: table this for the moment

<AxelPolleres> I think further, we could probably not get anything more than a "principle of maximum reuse" and something like defining BLD and PRD as core in the following sense. Proposal:

<AxelPolleres> Other dialects should reuse BLD and PRD wherever possible. Other dialects MUST agree with the semantics of BLD and PRD on the parts (of the abstract model) they share with BLD and PRD.

<Harold> Starting from the 'largest' base dialect(s) will exclude starting from the 'null' dialect except when defining a totally different language (unrelated to the rest of RIF).

csma: is it possible to tell when ASP and WFS agree?

<sandro> Merging: wfnaf in one file and smnaf in the other, and you merge them..... document-level flags wont allow that.

mk: no. it's undecidable, but some sufficient conditions (stratification at the predicate level) exsist

<AxelPolleres> -1 to document level flg for the moment, not convinced yet. the smsnaf vs wfsnaf issue could be solved with different identifiers for the different nafs.

<Harold> 'Document-level flags' correspond to the XML attributes I mentioned earlier: Eg. a 'flavor' attribute for Naf, which distinguishes well-founded, ... semantics.

<sandroPost> scribeNick: AdrianP

Document publication plan

csma: document publication plan
... how many documents; which ones; why, what dependencies, etc

<sandro> mk: 1. arch with fallback + extesnibility stuff 2. two for logic

michael: ideally architecture document (fallback, extensibility), logical framework, production rule framework
... Framework for BLD and PRD

<Harold> http://www.w3.org/2005/rules/wg/wiki/FLD

<Harold> shuffled material from BLD.

michael: seperate documents, e.g. ARCH document, CORE framework, BLD

<sandro> csma: rule of thumb -- different audiences == different documents.

Michael: we would have very large documents otherwise
... signature, semantics etc are currently in BLD and should be moved

csma: compatibility of dialects with OWL, RDF, compatibility of PRD to XML schema
... shall this be described in an extra document?

chris: + different framework for PRD?

chrisw: Arch could be split into different documents?

michael: CORE is postponed after PRD

csma: do we need a core for different dialects

chris: interchange and overlap covered by Extensibility document?

axel: principle of extensibility needs to be written in Extensibility document

<AxelPolleres> As proposed earlier:

<AxelPolleres> " Other dialects should reuse BLD and PRD wherever possible. Other dialects MUST agree with the semantics of BLD and PRD on the parts (of the abstract model) they share with BLD and PRD."

sandro: as a user you are interested in the core (overlap)
... this overlap should be extracted and written down

chris: Is Core is an instantiation of guidance how to interchange two dialects

csma: Instead of having a Core could it be a profile of PRD and BLD?

<Harold> The 'Core' overlap (based on the Condition Language) of BLD and PRD consists of the Pure Production Rules we had discussed early on and its extensions (e.g., by Naf, Bagof, ...).

Sandro: intersections of dialects should be documented

<AxelPolleres> chrisW said: Extensibility should define how to specify interchange between two non-subsuming dialects. (Q: Do you mean by defining fallbacks? in that case agreed.)

<sandro> If there is a useful overlap, then it should be documented.

Jos: Extensibility talks about extension of XML syntax
... Framework talks about semantic extensions

Axel: Framework currently defines general notions of semantics, signatures

Jos: purpose of framework?

csma: example: PRD reused conditions of BLD, i.e. PRD points to BLD
... so it might make sense to take it out of BLD

jos: e.g. signature are not used

michael: signatures set the framework for extensions
... Framework creates the general framework how to create dialects by specialising
... Framework can evolve
... Framework is about logical extensibility

<AxelPolleres> Suggestion for what the "Framework" is:

<AxelPolleres> 1. Each RIF dialect MUST define a semantics (model-theoretic, proof-theoretic, operational in that order of preference).

<AxelPolleres> 2. Principle of maximum reuse: Other dialects should reuse RIF endorsed dialects (currently BLD and PRD) wherever possible.

<AxelPolleres> 3. Other dialects MUST agree with the semantics of RIF endorsed dialects (currently BLD and PRD) on the parts (of the abstract model) they share with BLD and PRD.

sandro: fallback mechanism is standard for RIF

chris: Extensibility and Framework need to be understand by dialect designer

<sandro> every fallback "programming language" has to be implement in every RIF consumer.

<AxelPolleres> "The RIF Semantics Framework provides means to define semantics for logical dialects and BLD is an example which uses this Semantics Framework. This does not preclude dialects to define their own semantics in a different way. However, reusing the Semantics Framework may ease the task of proving that a dialect fulfills (3.) above."

<GaryHallmark> Scribe: GaryHallmark

<scribe> ScribeNick: GaryHallmark

Public comments on BLD WD1 and RDF-OWL-compat WD1

not sure about the agenda item, but we are discussing public comments

dicussing comments from Peter Patel-Schneider

why 3 different kinds of atomic formulae?

this will be addressed in the semantic web compatibility doc

why is new treatment of data values needed?

josb: why different from rdf and owl
... difference is rdf/owl use data maps, but rif has fixed list
... rif does not use data mapping

michael: leaving data types open could be dangerous for rif

only 1 or 2 attendees claim to understand this distinction

chrisw: should this be an issue - fixed v. open data types

michael: how can RIF semantics handle open data types negotiated out of band?

josb: entailment checking would use out of band info, too

chrisw: need an action to determine difference in type handling and justify if there is a difference

<sandro> ACTION: jdebruij to explain in writing the difference in 'treatment of data types' mentioned in PFPS's comment [recorded in http://www.w3.org/2007/11/05-rif-minutes.html#action03]

<rifbot> Created ACTION-362 - Explain in writing the difference in \'treatment of data types\' mentioned in PFPS\'s comment [on Jos de Bruijn - due 2007-11-12].

why is there a symbol space for IRI identifiers?

<sandro> MK; to increase uniformity.

<sandro> ACTION: kifer to make a wiki page for replying to PFPS and start drafting reply, including explain why the symbol space for IRIs. [recorded in http://www.w3.org/2007/11/05-rif-minutes.html#action04]

<rifbot> Created ACTION-363 - Make a wiki page for replying to PFPS and start drafting reply, including explain why the symbol space for IRIs. [on Michael Kifer - due 2007-11-12].

treatment of slotted formulae is "unusual"

chrisw: ask Peter if it is a problem

condition language is very complex

josb: 3 frame formulas, slotted predicates, etc.

harold:  it's not "complex", it's "rich"!

sandro: could be simpler

chrisw: some of these comments don't need a response

why worry about interpretations where IP is not a subset of IR?

<sandro> ACTION: jdebruij to respond to '"Why worry about interpretations where IP is not a subset of IR", explaing how keeping the option of RDF Entailment open. [recorded in http://www.w3.org/2007/11/05-rif-minutes.html#action06]

<rifbot> Created ACTION-364 - Respond to \'\"Why worry about interpretations where IP is not a subset of IR\", explaing how keeping the option of RDF Entailment open. [on Jos de Bruijn - due 2007-11-12].

<sandro> Jos: you can no longer have ill-types literals in RIF.

<sandro> ACTION: jdebruij to draft reply to PFPS about il-typed-literals and make sure Chris likes it [recorded in http://www.w3.org/2007/11/05-rif-minutes.html#action07]

<rifbot> Created ACTION-365 - Draft reply to PFPS about il-typed-literals and make sure Chris likes it [on Jos de Bruijn - due 2007-11-12].

josb: latest draft ties rdf:type and rdfs:subClassOf to # and ##

no actions on RIF-OWL compatibility

why are xsd:date, boolean, float excluded but xsd:int are required? Why is xsd:integer the only derived datatype?

csma: not really done on purpose

what is the arity of #Imadethisup

Implementation plan

discuss implementation plans

who plans to implement bld?

axel: will not implement function symbols

<sandro> Kifer, Adrian, Harold, Igor, Axel--partial, Sandro

<sandro> kifer: in and out translators for XML, ... I don't know, toward end of 2008. If only presentation syntax then flora-2 already implements all of this.

<sandro> sandro: i certainly plan to implement translators between XML and presentation syntax, .... but PS isn't real.

<sandro> kifer: I doubt anyone can really implement equality.

<sandro> csma: implementation means that you can produce and consume RIF BLD documents.

<sandro> kifer: some substitutions are very expensive to do.

sandro: python translator for N3 and prolog

<AxelPolleres> axel: I would implement what can be handled by our engine, ie. datalog, w/o equality, but I could use RDF as data and would try to look into NAF extensions based on that.

adrian: translate to/from prova (an iso prolog language)

<sandro> ?

<sandro> 2-3 months

<sandro> prova == prolog + java

<sandro> adirian: I'd use XSLT

<sandro> Harold: OO-jDREW

<sandro> Harold: I'd also use XSLT

<sandro> Harold: estimate completeion end of 1Q08

adrian: would wait for stable bld spec

<sandro> Mike: Did SWRL to BLD, XSLT.

<mdean> http://www.w3.org/2005/rules/wg/wiki/Implementations/SWRL

<mdean> next step: validate output against just-published XSD

<sandro> Igor: we're mostly interested in producing RIF rules, from our machine learning systems. we need builtins, lists, NAF, ... first.

igor: leverage another rif consumer to execute what we produce

<sandro> Igor: we'd want to use consumer, based on Flora or Prolog. It should take a couple months, after BLD is really fixed -- not at this stage.

<sandro> Axel: I want a hook in the language for referring to RDF data sets.... I want something quick based on the presentation syntax.

<sandro> Axel: ~2 months, when we have RDF reference mechanism.

<sandro> Chris: implementor's breakout tomorrow....

<sandro> PaulVincent, Gary, Stella, Bob === waiting for PRD

<sandro> Jos - academic, at the moment.

<sandro> ilog == prd as well.

<sandroPost> scribeNick: Harold

RIF-PRD strawman

csma: http://www.w3.org/2005/rules/wg/wiki/PRdialect
... walk-thru explaining assumptions etc.
... Formal description based on Claude Kirchner et al.'s rewriting approach.

(from project MANIFICIO)

MichaelK: You have semantics in two places, one not used.

csma: maybe one to be removed.

Gary: Hard to discuss semantics before having any syntax.

csma: Occasionally useful.

Gary: OK, on the level of deciding model-theory, operational, etc. semantics.

csma: Removed pattern language section.
... Reuses condition language.

Jos: Thought you dont support function symbols?
... Actions in the 'head' (then-part) of rules. But action lang. extends condition language.

csma: Two actions: Add/Remove a fact.
... Not an extension of Condition language, but new lang. on top of it.
... OK, but only first draft.
... Copied from BLD: 1.3.2 (Why is it a Web lang., ...)
... Diff from BLD: Structural diagrams and XML for syntax. No presentation syntax.

Gary: Why none?

csma: Not needed.

MichaelK: But it's on the first page.

Gary: PR vendors will want to see a presentation syntax. To discuss what a given snippet means.

csma: Starting from the botton.

Jos: Another use of pres. syn.: didactic, introductory reasons.

csma: Audience for PRD more developers than academics, so more interested in XML.
... E.g. Mark Proctor said: "... just give me the XML syntax involved..."
... Took BNF syntax principles from WSDL.
... E.g. defined_element contains BNF (comment?)
... Condition lang. with a few modifications: simplifications such as removing some things.
... Classification only uses Membership. Frame only with one object, one slot (deal with the rest in the XML syntax as syntactic sugar).

Gary: ALso see it as too general in BLD?

csma: Yes.

Gary: Let's resist temptation to try in PRD to fix issues of BLD.

csma: TERM

Gary: If you get rid of Uniterm then you dont have nested functions, which are not present in production rule systems.

Sandro: For calls you dont want to distinguish if they are builtins or user-defined.

<AxelPolleres> If we don't syntactically distinguish built-ins, I am a bit worried about extensibility, honestly.

MichaelK: builtins in both head and body?

<AxelPolleres> Why should a thing in one dialect be a logical function and in the other a builtin??? THat would be the result of not syntactivally distinguishing them, or no?

csma: Yes, but no problem since there are no function symbols.

<sandro> Not in one dialect vs another --- one *implementation* vs another.

<AxelPolleres> same with interpreted functions.

csma: Tried to be compliant with PRR.

<sandro> Like, append/3 can be a built in or a library function.

<AxelPolleres> or a logical function :-)

<sandro> library function == logical function, as I meant it.

csma: This community is more development oriented. That's why added more than absolutely necessary.

<AxelPolleres> ok, so, how to distinguish? each dialect needs to specify which are built-in (ie. fixed interpretation) and which are logical (ie. variable interpretation) functions/predicates?

csma: NonMonNot is neutral with respect to earlier discussion about negation.

<AxelPolleres> and obviously the symbol spaces need to be disjoint for those.

csma: TERM like in BLD -- could become a substitution group.
... Const copied BLD part about symb. spaces.

<sandro> In dialect1 append/3 is not built in, so if you want it, you must somehow cause its definitional as a logic function to be loaded. in dialect2, append/3 is built in. [I'm not saying this is absolutely the best way to do it, but it has some advantages.]

csma: Keep 'type=" ... IRI ..."

<AxelPolleres> "NonMonNot is neutral with respect to earlier discussion about negation." ... If we would have had (general) NAF in the condition language, would you have reused it?

<sandro> actually, this probably violates No-Language-Conflicts....

<sandro> this == my side conversation here about append/3.

<AxelPolleres> yes, that is what worries me, sandro.

csma: Even inlined examples need no pres. syntax: <Const type="SYMSPACE">LITERAL</Const>.

<sandro> Yeah, I think you're right, Axel.

csma: Different communities -- different ways to write rules.

Gary: Dont think this at all. Only want to see 'deltas' w.r.t. BLD, not need to learn pres. syn. from scratch.

csma: I thought people from ILOG, ORACLE, etc. will directly start to read PRD (dont need to read BLD documents).

<AxelPolleres> As for the nonmonnegation... I, from an abstractModel point of view, ask myself is NAF a subclass of NonMonNegation or the other way around, or are they completely unrelated?

<AxelPolleres> (conceptually, they are obviously related...)

Paul: Potential use case: could use logic or production rule approach.

Gary: Perahps it was a historical accident that business users chose prod. rules, not logic rules.

csma: Gary, I agree that BLD and PRD docs should LOOK the same.
... Would argue BLD should be restructured like this, by components (not as a whole), would make it easier for developers.

Gary: Better to be common than to be slightly better: Lets not try to do BLD changes in PRD.

csma: If it makes sense as now in PRD, then the BLD team will take it over, otherwise not.
... Point is NOT to compete between BLD and PRD.
... Only the presentation/structure of the PRD document seems to be useful.

Jos: Concern that a lot of material of this PRD draft is a repetition of what's already in BLD. But it should only be in ONE place.

csma: Yes.

Jos: I thought we dont want to have negation in Phase 1. Now it's in PRD.

Sandro: OK for exploratory purposes.

Gary: Until we dont have such extensions of the Condition lang. we should ask them to add them, not invent them in PRD. Rather PRD should move on to formalizing Actions.

Sandro/Axel: Which kind of negation is appropriate for production rules.

<AxelPolleres> sandro, we don't have subclassing in XML, but we do have it in RDFS :-)

Harold: Granularity of reuse better when there are sublanguages of the Condition lang.

<sandro> csma: I really want a common component library, and maybe a common core. BLD and PRD should draw from those, but not have to be exactly the same.

csma: Library of constructs may be advantageous.

<AxelPolleres> I think, which I said already some times admittedly: s/ common Core

<AxelPolleres> /common abstract model/

AdrianP: Many Reactive lang. have such a library.

<AxelPolleres> that would keep the "component library" somewhat "dialect independent"

csma: Uniterm: We cannot say informally only in the spec that the arg order matters.
... Semantics of Uniterm: mapping function.

Axel: No semantic difference between builtins and user-defined functions.

csma: Currently, not distinguished in BLD.

<sandro> AxelPolleres, while we have subclassing in RDFS, do you think we can mandate that RIF Consumers do complete RDFS reasoning before extracting the RIF semantics structures? That seems like a fairly hard sell to Gary. :-)

csma: in PRD we have fixed interpretation functions.

<ChrisW> Scribe: Harold

Gary: Plus: all args of builtins must be ground.

csma: Yes, that was in the patterns.

<AxelPolleres> For Gary, nothing changes, I don't say that the XML syntax for PR needs to accept <smsnaf> in place of <naf>

Gary: So we have no universal semantics that tells us for every expression if it's true or false.
... Would be nice to have a more general semantics for both.

<AxelPolleres> but a stratified datalog dialect should maybe accept sms-rulesets, as long as they are stratified.

<AxelPolleres> At least by subclassing , you can define some trivial fallbacks.

csma: That this is not (only) a model-theoretic semantics is even clearer for the And: works also for operat. semantics.

<sandro> Attendance note -- observing for the afternoon has been Carine Bournez, http://www.w3.org/People/carine/ (The RIF meeting is listed on the conference schedule as being open to observers, by accident.)

<AxelPolleres> i.e. if a dialect supports the conceptual superclass semantically, the default fallback would be replacing the special with the more general one.

MichaelK: You have to be careful where you are talking formally and where informally.
... We prioritized model-theor., then fall back to operational, then to procedural.
... But this is none of these, it's mixed.

csma: It's formal (although written in English).
... Define when a condition is true.
... then execute the actions.

MichaelK: OK, but it's kind of confusing. Suppose I read this, but wont understand.

<sandro> AxelPolleres, so the subclass relationships in the abstract model automatically generate some fallback substitutions? My guess is that's reasonable and somewhat helpful, but I'm not sure.

csma: This is why put sem on top.
... Dont see why this is not formal.

MichaelK: First do syntax, then semantics.

<AxelPolleres> that would be the idea... also not 100% sure, needs some dialect examples, which I still owe, admitedly.

MichaelK: E.g. it's not interpreted as a function from to, everything is regarded as matching.

<AxelPolleres> ... but it sounds appealing to try to me

csma: The pattern matching mechanism gives me the function.

Chris: What do you regard as the interpretation function?

csma: A mapping to a domain element.
... What does pattern matching do? Tells you what's the interpretation!
... Tells you what's and what's not in the interpretation.
... But what I get from discussion: This is confusing. Not the right way to put it in a spec.
... However, the earlier approach also seemed confusing.
... Wanted to keep it as close to BLD as possible.

Harold: Much better than earlier version.

MichaelK: What's wrong: You say here's a program, I determine from a procedure what the meaning is. The wrong way round.

csma: Perhaps misunderstanding.
... Removed pattern section.
... Actions have to be worked on.
... Gary's point is valid that top-level of Rule syntax is different unnecessarily from BLD.
... But this is because BLD is not frozen yet.
... Could perhaps just one CONDITION rather than two. Historical from earlier patterns and the 'else' parts. But it may be good to keept both.

Restart at 4PM.

<StellaMitchell> ScribeNick: StellaMitchell

Builtins

csma: we didn't consider carefully which xsd datatypes to pick

Chris: Yes, we settled on a set during one of our meetings
... (projecting list of xpath functions and operators)

http://www.w3.org/2005/rules/wg/wiki/List_of_functions_and_operators

jos: will these be predicates or functions in BLD?

Chris: do we have notion of builtin as external call? are all predicates, all functions ?

Harold: telecon with DARPA demo group - we chose a fixed interpretation for builtins
... the point is - we have equality in RIF

mk: if we assume URI's identify functions, we can

Harold: mode declaration of functions
... for now, it would be very nice to have builtins as functions

axel: for predicates, it is not so clear what is input and output

<sandro> binding patterns == modes

<sandro> Harold: non-deterministic builtins

Harold: (something is) then you would have non-deterministic functions

Sandro: trying to clarify between functions and predicates
... you might have extension that has more builtins (that the dialect it extends)

<Harold> Because in RIF we have Equal, we can finally come back to builtins being functions, not (artificially) relations. Advantage: uniform mode declarations.

Sandro: can lead to a language conflict (syntax has different meaning)

Chris: Also, datatype extensibility is an open issue

<sandro> Sandro: It should be a syntax error to use a builtin that's not in some dialect.

Chris: I don't think it makes sense to assume the list of builtins is fixed

Jos: xpath uses namespaces, but we use curies...

csma: functions as relations, means uniterms of the atomic kind?
... so the only uniterm of the term kind are logical functions

mk: asking about xpath urls, namespaces, what is behind it?

axel: reads definition from xpath spec

Sandro: they are available to users as other symbols

<Harold> For example, NumericAdd has uniform mode In x In -> Out as used in ?Result = 23 + 17 or
<Equal>
<Var>Result</Var>
<NumericAdd><Const>23</Const><Const>17</Const></NumericAdd>
</Equal>.

<AxelPolleres> http://www.w3.org/TR/xpath-functions/#namespace-prefixes

Chris: back to questions - builtins as relations or external calls?

csma: what is the difference?

sandro: diff between interpreted and logical functions - for interpreted, you have to call some other piece of code to evaluate it

csma: Allowing user-defined interpreted functions?

sandro: that wouldn't allow for extensibility

csma: producer and consumer have out of band agreement on what it is
... function names are iris, so if you can't recognize it, you don't handle that external functions

sandro: no, in that case it could be a logic function

csma: I can't think of any concrete case where it would be a problem

sandro: append - would be reasonable as either

Chris: what is the status of functions in BLD
... how does a user define a logic function?

Gary, MK: they just use it

<sandro> "logic functions that are term constructors" vs "evaluable" or "interpretable" functions, ....?

<Harold> In my example, NumericAdd as a relation would have hetereogeneous mode Out x In x In.

sandro: an "eval" function

<sandro> "external call", "procedural attachment", ...

sandro: it's a little confusing that an external call is a builtin
... issue is, if you can tell from the syntax whether it is a builtin or a logical function

Chris: is anyone opposed to having a special syntax to distinguish?

<Harold> We already can define functions using ATOMIC Equality facts based on ATOMIC ::= Uniterm | Equal.

csma: if we want fully stripped xml syntax, we need elment

mk: builtins are supposed to have a uri, and in semantic web uri already has a meaning, so from that point of view we don't have to say anything

sandro: gives example showing it is more complicated

mk: uris are supposed to be self-denoting

sandro: op:numeric-add is self denoting

Chris: is it possible to define syntax and that would indicate which it is?

<Harold> We can user-define as an equational fact fatherOf(Mary) = John or
<Equal>
<Uniterm><Const>fatherOf</Const><Const>Mary</Const></Uniterm>
<Const>John</Const>
</Equal>.

mk: no, I don't think so

sandro: dereference argument and get documentation and links to downloads
... but from point of view of semantics, it is just an opaque string that denotes a function

Chris: syntax that denotes builtins, and spec says which ones have to be supported
... and people would be able to add more

mk: we can't control what is at the URL of fn:compare

sandro: uri goes to the text description

<AxelPolleres> <Uniterm> vs <Builtinterm>

Chris: advantage of having an explicity syntax is that it is open - people can add more
... who thinks we should special syntax to identify builtins?

(people on both sides, there is disagreement)

Harold: in lisp there is a uniform way to call user defined and builtin functions

Chris: but in lisp, it is not open

BobM: ??

axel: you are saying builtin terms must always have fixed interpretations

<sandro> "ExternalUniterm"

mk: I think we can make it extensible

Chris: but you are signalling it syntactically, like with defun

mk: I would use "require" (the list of bld functions)

sandro: that is not extensible

mk: we only care that a symbol is used consistently
... if not, things are broken anyway

sandro: "append" example, where it could be either builtin or logical function

mk: but it would have different uris for different uses

axel: what if the builtin is in the head (conclusion)?

Chris: we can discuss that later, after we resolve this questions
... if we syntactically mark builtins, it is very clear how it would work
... but some people here think it's cleaner to not have to syntactically indicate it
... proponents of not syntactially marking can try to come up with a suggestion, maybe in a break out tomorrow

<sandro> Chris: Result --- default is External Calls In Syntax; people who want something else (including him) need to come up with a proposal.

Chris: that group will come up with a proposal or agree to the other method

<Harold> Looking at

<Harold> <Uniterm>

<Harold> <op><Const type="rif:local">fn:subtract-dateTimes-yielding-dayTimeDuration</Const></op>

<Harold> <arg><Var>deliverydate</Var></arg>

<Harold> <arg><Var>scheduledate</Var></arg>

<Harold> <arg><Var>diffduration</Var></arg>

<Harold> </Uniterm>

Metadata

Chris: metadata
... meta means "after"
... what metadata do we need?

<Harold> the "fn:" in fn:subtract-dateTimes-yielding-dayTimeDuration shows that we have an external call here.

Chris: which syntactic terms can have metadata?

<Harold> However there are some ways to mark this more explicitly as a builtin call:

Sandro: and other questions about metadata: is the metadata fixed for a given dialect?

Chris: you mean is there a finite set of preset tags?

sandro: yes

PaulV: is it extensible?

<Harold> * Use <Const type="rif:builtin">

Sandro: or rather, if you want a new metadata item, do you need to make an extension?

Gary: can you always ignore the metadata and get the same result?

<Harold> * Use <Const type="rif:local" builtin="yes">

PaulV: what is an example of metadata that cannot be ignored?

<sandro> csma: is rule priority metadata?

<sandro> csma: it affects semantics.

jos: if you refer to a datamodel using metadata, and that datamodel affects the semantics

Sandro: this is why I advocate having no metadata

Adrian: example of using RIF document as data

<sandro> no metadata mechanism --- just more extensions.

Chris: do we want to talk about a class of metadata that cannot be ignored?

csma: I think Sandro had a good point. We don't call it metadata, just data

<Harold> * Both of the above are much better than using a totally different calling method such as <ExternalUniterm>, because the transition from user-defined to builtin should be kept as simple as possible (see above discussion about lisp and prolog).

Sandro: I suggested pushing this off until we understand extensibility better

Chris: It should not be that you need an extension to add author metadata

csma: isn't metadata the things that don't have to do with semantics

mk: dublin core

PaulV: and that (dublin core) would be a good starting point for RIF

jos: we shouldn't have a fixed set of metadata - it's just a set of attribute value pairs

sandro: so properties are iris and values are strings?

mk: sandro, what did you want?

sandro: import dublin core wholesale

<Harold> I think metadata should be non-prescriptive annotations, i.e. not change the normative semantics of a ruleset.

<PaulVincent> http://dublincore.org/documents/dc-xml-guidelines/

mk: how does owl do it?

jos: they say you can use any metadata you want, as long as it is an annotation property

Chris: I think that agreeing on specific metadata tags should not be part of dialect defintion - just say how to include metadata
... who thinks the set of metadata for a dialect is fixed?
... strawpoll

csma: can we have both? a required set and a way to add more?

Chris: 3 proposals:
... 1 fixed
... 2 open

<Harold> Metadata thus act just like comments from the perspective of the normative semantics, although non-semantics-preserving processing such as in AdrianP's author-filtering example will be possible.

Chris: 3 required, plus a way to add more

sandro: I object to passing a resolution now because we hav not settled on our extensibility mechanism

official count: fixed: 1, open:4, mixed: 6

Chris: We will put on hold the question of where we can put metadata (which elements to attach it to)

<sandro> Chris: Non-ignorable metadata is part of a dialect. I think we have consensus.

Chris: non-ignorable metadata is part of a dialect definition

bobm: i'd say non-ignorable metadata is not metadata

<sandro> Sandro: So the question is whether to have an annotation mechanism for ignorable content.

<sandro> Gary: 'this rule is effective during the month of november' --- is that metadata?

Chris: the mechanism we are talking about is the annotations that don't affect the semantics
... ( the ignorable metadata)

<Harold> +1 to bobm

<sandro> The issue here is whether to provide a syntactic mechanism for including structured annotations which have no effect on the semantics. And if so, how?

<sandro> (Avoids the term metadata)

<sandro> general consensus on that issue statement.

<PaulVincent> Paul: proposes some use cases for metadata eg RIF for execution won't need metadata eg RIF for rules mgmt will find metadata significant

<sandro> Sandro: I'm not convinced we need this, yet. I think light-weight extensions might cover these use cases.

<mdean> scribe: Mike Dean

Chris: we will discuss it more after we settle on the extensibility mechanism

<mdean> scribenick: mdean

test cases

ChrisW: overview of test cases in WebOnt WG

entailments for each operator

resolution of issues often documented as test case

<Harold> http://www.w3.org/TR/owl-test/

ChrisW: RIF could adopt this methodology

Sandro: consistency tests too?

<sandro> Agreement -- we need Inconsistency and Consistency tests too.

csma: have people submit cases where they think there is ambiguity
... what is the form of these tests?

example test case in Stella's email above

structured annotations wrapping OWL documents

premise in one file, conclusions in another

<josb> owl example: http://www.w3.org/TR/owl-test/byFunction#function-Restriction

message uses example URIs - OWL tests were real

Sandro: likes .hrif for presentation syntax
... Jeremy Carroll wrote nice software to manage test cases for WebOnt
... recently asked to resurrect this for OWL WG
... Jeremy and Jos deRoo just did it

Adrian: need separate query language?

ChrisW: not needed - just specify in manifest
... can we leverage JUnit?

Sandro: let's wait for a few weeks on OWL WG

ChrisW: need time limit

Sandro: ... unless someone else volunteers
... could still submit a test in natural language in email or Wiki page

josb: good to link to examples in document

csma: some tests should also be linked to use cases

Sandro: group seems to be comfortable mirroring what OWL did

csma: what about testing implementations?

Sandro: WebOnt generated table of tests by implementation, showing each was handled by at least 2

csma: could be a way to test that specification meets requirement, i.e. was implementable

Sandro: doesn't ring any bells

compliance

Sandro: prefer conformance

csma: yes/no test or degrees of conformance?
... define profiles/levels

ChrisW: based on test cases that implementation passed, not a formal thing

josb: normative OWL test cases section on conformance
... syntax and consistency checkers

parking passes distributed

<Harold> We need to make entailment ( |- ) relative to the logic we are in. Eg in FOL p(a) :- q(a) |- ~q(a) :- ~p(a), but not so in Horn logic.

Sandro: strawman conformance test: phrase as some sort of ACTION: this software does this ...

csma: prefer one level of compliance - must implement everything
... then could have compliance for specific extensions

Michael: most implementations probably won't implement full equality
... OWL has not been fully implemented either

josb: Pellet isn't complete with nominals

Sandro: unfortunate that we don't have complete OWL implementations yet

Michael: same with SQL, thousands of pages of spec
... don't exclude something just because it's hard to implement

csma: compliance is like conformance but not quite :-)
... want to promote adoption, motivate comfortant implementations

Michael: could be conformance level that doesn't include equality

csma: could end up with so many dialects and levels that OWL looks simple

<Harold> The paramodulation calculus is a refutational theorem proving method for

<Harold> first-order logic with equality, originally presented in Robinson &Wos (1969)http://www.cs.bu.edu/fac/snyder/publications/BasicParamodulation.pdf

<sandro> Chris: Issues 1 - whether to have levels of conformance (vs just boolean) per dialect

<sandro> Chris: Issues 2 - whether to have lowest conformance level match implementations (eg full equality).

bob: many features aren't implemented or implementable with reasonable time
... interoperability is most important
... don't define logic that can't be implemented

<sandro> Chris: 4 square, levels vs expected.

csma: boolean might not require equality

profiles not the same as levels

Chris: boolean per dialect

Michael: profiles are kinds of dialects

straw poll

<sandro> Chris: Levels + Expected: 0

<sandro> Chris: Booleans + Expected: looks like everyone

<sandro> Chris: Boolean + Not-Expected -- Michael

<sandro> Michael: There will be useful implementations which don't conform.

<Harold> The axioms for the equality relation need not be built into RIF (without it's easy to implement), because they can be 'loaded' as another ruleset: http://www.math.psu.edu/melvin/logic/node7.html

Chris: does everyone assume profiles?

6 of N-1 thought they were voting for profiles

<sandro> Voting for profiles: 6,

Sandro: voting for compliance being something that's implementable

Chris: BLD - equality not a profile?

Sandro: change BLD to not include equality

csma: current BLD becomes an extension

<sandro> Sandro,Bob: define BLD as something that's implementable.

+5 for Sandro

<sandro> 5 people agreeing with that view.

csma: same for PRD
... extensions could be harder to implement

Sandro: profile vs. extension is marketing difference

csma: important for adoption

Sandro: same for equality and negation

Chris: plenty of SQL operators are partially implemented
... nobody needs the full implementation

csma: must jump start implementations

Chris: not ready for resolution, but consensus that we want boolean tests for conformance with some disagreement over what to test

Michael: could also use test cases

Chris: industry likely to do this, publish their test case results

Sandro: BLD querying system vs implementation

Chris: do we need issue regarding equality?
... always boils down to test cases

<sandro> group of five who wants BLD changed to remove quality, so that it's practical to implement it fully

<sandro> ACTION: Christian to open issue about removing equality from BLD because it's not so practical to implement. [recorded in http://www.w3.org/2007/11/05-rif-minutes.html#action09]

<rifbot> Created ACTION-366 - Open issue about removing equality from BLD because it\'s not so practical to implement. [on Christian de Sainte Marie - due 2007-11-12].

adjourned