<StellaMitchell> dialling...

<sandroPost> scribeNick:IgorMozetic

chris: possible breakout sessions: implementors (BLD), PRD,

<sandro> (only Jos not interested in either breakout.... :-)

axel: let's talk about the structure of the extensibility doc in the afternoon breakout

extensibility (fallback)

chris: fallback mechanisms

sandro: for any new dialect or extension one should also publish the fallback procedure

axel: impact depends on the dialect one fallbacks from

csma: fallback must be implementable at the translator level

sandro: fallback processor is (can be) external program

<PaulVincent> Fallback: default = reject with exception

csma: any implementation of any dialect has to implement the fallback procesor

<PaulVincent> What are the fallback use cases? is this even an issue? (May be in the Sem Web world but for PRD it would seem to be very unlikely)

axel: fallback can be a service

gary: is producing several versions of rules fallback?

sandro: no

<AxelPolleres> I think allowed fallbacks to existing dialects should be defined together with new dialects.

sandro: the fallback procedure is attached to the dialect, not specific rules

<AxelPolleres> Also, we need a protocol, which tells how you processed a ruleset.

<AxelPolleres> i.e., "processed ruleset with the originl semantics", "processed ruleset using fallback X to dialect Y, etc."

<AxelPolleres> fallback from sms to stratified naf: check if stratified, if yes replace "smsnaf" by "naf", if no

<AxelPolleres> return error.

sandro: some fallbacks are lossy, some are strict

<sandro> 3.1+ Trim To Named Ancestor

<AxelPolleres> I can describe the fallback I sketched from-strat-naf-to-bld by rules easily, I am pretty sure...

<AxelPolleres> ... not single-pass though, probably.

sandro: one can always use XSLT transformations
... XSLT vs BLDX

<sandro> Sandro: I would like feedback from the WG about whether we think about fallback in XML terms or Frame terms.

<DaveReynolds> A challenge with BLDX is that BLD is about deduction not about transformation. How would you use it to specify rewrites? PRD on the other hand is probably better suited to that use :-)

<PaulVincent> +1 although it might be a step too far right now...

igor: I don't see any problem in defining transformations in BLD
... eg, rewrite(Src, Trans) :- ...

<sandro> Sandro: fallback is the ontology-mapping problem, so deduction is okay, Dave.

<Harold> If we 'trim'-transform the Hornlog ruleset { p(a) q(f(b)) } to the Datalog ruleset { p(a) } we lose completeness; if we 'trim' it to the Datalog ruleset { p(a) q(b) } we lose soundness. Transformations to a flattened version like { p(a) q(f b) } could work if all queries, like q(f(?X), to that ruleset would be correspondingly transformed, like q(f ?X).

<AxelPolleres> If you go via the RDF abstract model of a rule set, you can use SPARQL constructs to define fallback transforms.

josb: claims that production rules are much more convenient for transformations

<DaveReynolds> Not convinced that deduction is an adequate proxy for rewrite. If you can do the rewrite in one step that is OK but rewrites often do a series of reductions and it is the final reduced form you need to retain as the rewritten version. Sure you can specify the individual rewrites as equations but you need more than that to know what subset of what is "true" is the target rewritten form.

<AxelPolleres> +1 to Christian to not reinvent the wheel for rewriting formalisms.

<GaryHallmark> +1 to Christian to start with simple trim to fit or named trim to fit

axel: one can even use a natural lang to describe fallback

<josb> +1 to Gary, Christian: let's not make things harder than they should be

<GaryHallmark> people with complex fallback needs will figure out how to use xslt on their own with no help from us except they need as simple a schema as possible

sandro: we need the simple mechanisms like trim to start with fallback

<Harold> The encoding of a fact q(f(b)) to a complex term q(f(b)) is trivial in BLD since we use Uniterms for both. The signature will change, though. The encoded complex term would be the input of calling Igor's rewrite( q(f(b)), ?Trans ), binding ?Trans to q(f b) which can again be trivially decoded to a fact.

sandro: 3.2. where is the extension metadata
... this is about user extensions

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

<AdrianP> users will implement rewriting transformations anyway, e.g. for rule code refactoring or handling expressive constructs such strong negation in extended logic programs

sandro: do we need inline fallback?
... 3.3. how complex an impact structure?

<AxelPolleres> some suggested text:

<AxelPolleres> A FALLBACK from dialect A to B is a reference to a well-defined transformation (given in XSLT, SPARQL, naural language) which describes a transformation from rulesets in A to rulesets in B. The application of fallback F by a rules engine means that the ruleset in A will be treated by the rules engine as if the transformation was applied using an engine for dialect B.

<AxelPolleres> Each fallback MUST describe the impact of the fallback in terms of soundness

<AxelPolleres> and/or completeness.

<AxelPolleres> A RIF system can answer to a query indicating whether it processed the dialect the documant was given in or whether it used a fallback, pointing to the used fallback

chris: fallback might be regarded as constraint relaxation

<AxelPolleres> For the impact on completeness on soundness in the search enine scenario, see: http://www.polleres.net/publications/poll-etal-2006b.pdf (about scoped negation and context monotonicity)

josb: re table: soundness and completeness are boolean,
... while number of extra/missing results can be qualified

<sandro> Sandro: Extraneous Results == "Soundness", Missing Results == "Completeness"

<sandro> Jos,Chris: soundness bit, completeness bit, extraneous results level, missing results levels, ...

<sandro> csma: inline data is useful for cases where fallback/impact information is known for a particular ruleset.

<sandro> sandro: yes, indeed.

chris: let's collect examples of different cases of fallback

sandro: 4. Strawman

<AdrianP> Examples for transformations are e.g. the Lloyd-Topor transformations, e.g. replace disjunctions by two rules

harold: shouldn't XSD be part of the document

sandro: the schema is needed for translators (Gary), not each document
... BLD can proceed even without saying much on extensibility

<DaveReynolds> Do profiles relate to extensions? I can see lots of partial BLD implementations rather than lots of BLD++ implementations. Describing that profile seems important to me.

chris: each implementation of BLD will be its own dialect

igor: strongly disagrees, each implementation should be for a specific dialect

<sandro> http://www.w3.org/2004/12/rules-ws/report/#conclusions

<Harold> I just chatted with MichaelK: Both of us would be fine to omit Equal from BLD for now (and regard BLD=, with Equal, as an extension). This would increase chances that BLD could be completely and efficiently implemented soon. Actually, I already distinguished Horn (without Equal) from Horn= (with Equal): http://www.w3.org/2005/rules/wg/wiki/Arch/RIF_Components/RIF_Dialect_Structure

<DaveReynolds> It's not about good/bad people! BLD has no particularly strong correlation to the languages we are to implement translators for.

Implementation (breakout session)

<sandro> This is the BLD-Implementations Breakout.

<sandro> Harold: Transformations vs Engines.

<sandro> ... at NRC, we've looked at XSTL transformations

<sandro> ... One student hopefully working on RIF reader for ooJDrew.

<sandro> ... Variables can be restricted with classes.

<sandro> ... Preliminry treatmen of URL; anchor fact or rule with URL, then retreive based on URL

<sandro> ... Prolog engine using iterative deepening.

<sandro> oojDrew has POSL and a NAF-HornLog-RuleML as input languages.

<sandro> Harold: likely to do another direct-input-parser for RIF.

<sandro> Harold: RIF-to-* in XSLT can share a lot of XSLT.

<sandro> Mike: builtins will be a fair amount of work....

<sandro> ... We linked to Saxon for some of it.

<sandro> ... 60 swrl builtins

<sandro> ... about the same as here.

<sandro> ... maybe some like trig functions

<sandro> ... about a dozen, like string concat, could be in java -- but the semantics were slightly different.

<Harold> For coordinating the implementations, we could reuse/extend the List of Rule Systems: http://www.w3.org/2005/rules/wg/wiki/List_of_Rule_Systems

<sandro> ... not much of test suite. thought about leveraging xpath/xquery test suites.

<sandro> Harold: if we want builtins in datalog, then we're back to SWRL-style.

<sandro> Axel: work with Thomas Eiter, &builtin[input](output)

<Harold> ?x = add(3 4)

<Harold> add(?x 3 4)

<AxelPolleres> http://con.fusion.at/dlvhex/

<AxelPolleres> (that's the URL of the dlvhex plugin system)

<sandro> x=z+(y+3)/4

<Harold> add(?x 3 4 5)

<AxelPolleres> htat would be possible with the dlvhex plugins (since I can program variable input tuple length there)

<Harold> And( z=2 y=5 x=z+(y+3)/4 )

<sandro> if 5 < (1+2/3) * 4 then

<sandro> Harold: "floundering" a cyclic dependency between the modes of builtins, which makes re-ordering not simple (possible?)

<sandro> (from Lloyd, foundations of logic programming)

<Harold> x=z+(y+3)/4 <=> add(x quotient(add(y 3) 4))

<Harold> And( myequal(z 2) myequal(y 5) add(x quotient(add(y 3) 4)) )

<Harold> We need to do a kind of 'semantic query optimization' where add(x quotient(add(y 3) 4)) would be called only after the two other queries bont z and y.

<Harold> Mike: Who else could be interested in implementing BLD?

<Harold> Chris: SRI? Ontoprise?

<ChrisW> ACTION: igor to start an implementors wiki page [recorded in http://www.w3.org/2007/11/06-rif-minutes.html#action01]

<rifbot> Created ACTION-367 - Start an implementors wiki page [on Igor Mozetic - due 2007-11-13].

<ChrisW> http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies-20071026.html

<Harold> http://www.w3.org/2001/tag/doc/versioning#dt-extensible

<sandro> Under 3.16. XSLT -- that's like GRDDL

<ChrisW> http://www.w3.org/2007/uwa/editors-drafts/DeliveryContextOntology/2007-05-31/DCOntology.html

<sandro> DanC: trim-to-ancestor is like CSS -- ignoring the whole rule when there's a bad color named in it.

<sandro> http://www.w3.org/2001/tag/doc/versioning#dt-extensible

<sandro> violet -- one jar file UML editor

<Harold> Pragmatic Web: http://www.pragmaticweb.info/

<sandro> testing

Debriefing breakout sessions

<Bob> scribenic Bob

<ChrisW> Scribe: Bob

Reviewing breakout sessions

csma: PRD breakout

review document structure and then the semantics

on the document structure - want to have as large an overlap with BLD as possible however there are issues

for example PRD requires some idea of negation, even if it is not in first version of BLD

Gary's suggestion is to have single Wiki page to define common information

Sandro: horrible idea to have multiple documents containing large sections of identical text

<sandro> (specifically -- horrible for readers)

csma: virtue of single piece of text shared is it helps during the drafting process may replace later when move to final versions (either share or in separate reference document)
... to this might need to do some restructuing of BLD document to support this idea
... in discussion on approach taken in PRD, some of group had issues about the BLD's approach
... discussed some specific points on operational semantics big question was the strategy for selecting which rule to fire (given generally several can be applied at any time)
... all vendor engines have different strategies with some overlap, but much variation

<PaulVincent> Scribe notes from PRD breakout are emailed to the RIF mailing list FYI

csma: action to list strategies current supported by engines. Need to determine what (if any) common default strategies can be adopted

gary: do we need to (re) define operational semantics for the condition language for PRD or can we have a hybrid approach keeping model theoretic semantics for conditions and operational for rest of PRD

csma: explaining "recognition" phase of PR processing ("instantiating" the rules) to Jos

<sandro> common condition language....

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

<sandro> Harold: "pattern" vs "condition" in PRD?

csma: patterns are essential part of PRD

csma to explain to Harold difference between conditions and patterns

Sandro: summarising the BLD implementation breakout
... most of work is handling buildins - which is a lot of the work in terms of implementation

Mike: talked about different kinds of implementations

Sandro: talked with NA WG about extensibility and how they relate to RIF extensibily issues

<Harold> David Orchard: http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies-20071026.html

Micheal & Jos made some decision but they won't tell us what

Micheal: looking at ways of how to provide type compatibility with OWL

WG future

Chris: Topic should now be Working Group future
... at F2F7 decided we'd look to request a 6 month extension

csma: looking up what was agreed at last meeting

Have list of requirements to move BLD to be ready for last call

Sandro: impressed with progress on list since F2F7

speculation on what we meant by engine defintion .....

<sandro> jos: revisit modules, as needed for Last Call.

Jos: Modules needed for BLD LC?

<sandro> mk: I don't think we need modules in BLD 1.0 -- we can put them in the framework, experimentally, and maybe have them in BLD 1.1

Michael: May be able to get around this by moving "experimental" features out of BLD
... explaining modules

<sandro> mk: one module can define a concept, and another can refer to it. external theory.

concensus seems to be that modules are not required for BLD 1.0

<sandro> Chris: BLD needs some way to link to / refer to data, doesn't it?

Chris: do we need modules to manage external data in BLD?
... can we refer to external data

Jos: not currently, but easy to fix

<sandro> Chris: Modules provide a handle (URI) for it, and a way to circumscribe some data+rules, so that reasoning is bounded. These are the two functions of a module. You might want this for rules, for RDF, etc....

Chris: arguing that we need some notion of module

<sandro> mk: all we need is a piece of syntax in XML where you give a URI for where an atomic formula comes from.

Michael: we only need some kind of syntax to do this

csma: can use mechanisms based on IRIs

<sandro> Sandro: How much do we work on modules in the next six months.

<sandro> MK: Work out how to refer to data, and make sure that works for modules.

Sandro: a lot of business about modules is out of scope for phase 1

Jos: need some notion of external data for OWL and/or RDF graphs

Sandro: his concern is that modules may be difficult to incorporate in only a 6 month time window
... moduels are clearly an essential item in the longer term

<sandro> Sandro: My concern is that solving modules (cf ISSUE-33 plus external theories) may be too much for BLD LC. We may not be able to get this done in next 6 months.

Action on Micheal to open an issue on modules

<sandro> ACTION: mkifer to open issue on modules, distinct from ISSUE-33 [recorded in http://www.w3.org/2007/11/06-rif-minutes.html#action02]

<rifbot> Created ACTION-368 - Open issue on modules, distinct from ISSUE-33 [on Michael Kifer - due 2007-11-13].

<josb> use cases 2.7, 2.8, 2.10 require referring to RDF graphs/OWL ontologies from rule sets

<josb> http://www.w3.org/TR/rif-ucr/#Interchanging_Rule_Extensions_to_OWL

Harold: is 6 months long enough? We ought to do some "experiments" to demonstrate some interchange of information between distinct implementation

Sandro: Yes we should do this, but it doesn't need to be before LC

<sandro> it's part of CR

<sandro> csma: the reason to go for only 6months is that if we're not at LC by then, it's a sign something is wrong.

csma: idea of 6 months is to show that we can get to LC, not to finish work of the WG

Sandro: probably want to have two F2F meetings before May, who will come? (or rather who won't come to either)

<IgorMozetic> tentative location of F2F9: http://www.bled.si/EN/ in February

<sandro> PROPOSED: WG asks for 6 months extension. Plans to get BLD to Last Call and hold 2 more F2F meetings by end of May.

Harold: where will they be? Europe or US

<AxelPolleres> f2f9 proposals: http://www.w3.org/2005/rules/wg/wiki/F2F9

<sandro> (don't record explicitely that we're trying to figure out if PRD is feasible... people seem to think it is.)

<sandro> RESOLVED: WG asks for 6 months extension. Plans to get BLD to Last Call and hold 2 more F2F meetings by end of May.

Documents

<GaryHallmark> I do not want to give up on Core being the base for PRD

Do we want a CORE document again

is CORE a profile of BLD, or BLD an extension of CORE

Michael: first is better as we have a semantics for BLD, but not (at the moment) for CORE

<GaryHallmark> I should be able to write a Core ruleset and run on PR engine or logic engine

<sandro> mk: The reason to do core as a profile is that we only need on spec of the semantics (BLD) -- core is just a syntactic restriction on BLD.

<AxelPolleres> Core could simply reuse the semantics of BLD, being just a syntactic restriction.

<AxelPolleres> THe other way around, it is not so easy.

<AxelPolleres> Since, we'd need to split off the semantics.

Michael: couldn't we do the same by defining CORE as a restriction of PRD

Bob: how do we verify that the two defintions of CORE are conformant?

<GaryHallmark> could either extend Core to BLD and PRD, or restrict BLD and PRD to Core

csma: Idea of having a separate definition of CORE is so BLD and PRD (and anything else) work on a common basis

<sandro> Sandro: Editorially, Core might exists with syntax, test cases, but say "For formal semantics see BLD and PRD".

csma: (explaining) have a document section defining CORE, with BLD and PRD documents including or pointing back to it
... semantics defined at the level of BLD and PRD

Chris: (trying to clarify) does csma want a separate CORE document?

<Harold> This 'Intersection Core' would contain what we called "4. Pure production rules with only asserts in the action part" in http://lists.w3.org/Archives/Public/public-rif-wg/2006Feb/0256.html

<sandro> Axel: csma, are you opposed to having Core be a small document which defines a syntactic subset of BLD? Because that's an easy way to get core.

csma: can extract common syntactic part of CORE easily

<AxelPolleres> Needless to say that a core from BLD extraction via the abstract model approach is trivial... just add a bunch of more constraints which forbid function symbols and equality.

csma: has something in mind - but wants to show what he means

<sandro> Sandro: Core == BLD - Equality and - function tersm.

<AxelPolleres> Besides the Core-BLD relation would ALREADY be an example of how extensibility in RIF works:

<sandro> Harold: let's take equality out of BLD.

<sandro> Harold: Taking function terms out of BLD is tricky because of Uniterms.

<AxelPolleres> A dialect can be defined as a profile of another, then we can define an extension of Core by NAF of a dialect which is an extension of another, and we are basically done for a minimal demo of extensibility.

<AxelPolleres> I don't understand, why we should go for something more complicated, honestly.

Harold, Michael speculating on modificiations to BLD to remove aspects such as equality

Axel: we seem to be making things harder for ourselves

<Harold> The simplest 'profile' masking in http://www.w3.org/2005/rules/wg/wiki/Core/Positive_Conditions is replace the grammar rule TERM := Const | Var | Uniterm with TERM := Const | Var

Sandro: What do we mean by restriction? Is it at the XML level, the presentation syntax or somewhere else?

Michael: Can manage this by restricting the signatures - "its trivial"
... BNF specifies a superset of the language as it does not restrict you to "correct" rules

<AxelPolleres> you could have an own XSD, no problem, but you don't NEED to.

<Harold> The other change is from ATOMIC ::= Uniterm | Equal to ATOMIC ::= Uniterm.

<sandro> PROPOSED: Core will be defined as a profile of BLD, with a change in the BNF which (like change ATOMIC ::= Uniterm | Equal to ATOMIC ::= Uniterm ) and the corresponding change to the XML schema.

Michael: Don't need to change BNF, just modify the signatures and symbol spaces

<sandro> errrrr ---- I meant that to be about function-free --- not Equality.

<GaryHallmark> +1 to Harold: change the grammar

<sandro> PROPOSED: Core will be defined as a profile of BLD, with a change in the BNF which and the corresponding change to the XML schema.

<AxelPolleres> If you can show that the grammar can just be done by removing nonterminals and productions from the BLD gramma, that would nicely show that Core is a restriction of BLD. No problem with that.

<sandro> csma: I object to that proposal, because I don't want Core to be a profile.

<sandro> Jos: datalog variables have to be safe.

<csma> I object to that proposal because having Core specified as a profile of X

<csma> ...makes specifying a dialect that extends Core but not X more difficult.

<sandro> PROPOSAL: Core will be what is currently called BLD with Equality remove, function terms removed, and perhaps safeness.

<sandro> Igor: Maybe get rid of frames and slotted terms

<sandro> Chris: But they are just syntactic sugar, aren't they.

<AxelPolleres> csma, I don't understand your concern.

<sandro> csma: What about built ins?

<sandro> Sandro: maybe core should have evaluable functions (although not logic functions)

<sandro> Sandro: So we don't need to worry about builtins for this decision.

<sandro> PROPOSED: Core will be what is currently called BLD with Equality removed, function terms removed, and perhaps safeness. (Ignoring editorial issues for now)

<sandro> PROPOSED: Core will be what is currently called BLD with Equality removed, function terms removed, and perhaps safeness. We will not get rid of BLD. (Ignoring editorial issues for now)

<sandro> Bob: if we define core this way, semantically, ... when we want to incorporate Core in BLD -- how do we verify the semantics are what we want.

<sandro> csma: If we discover we cannot semantically extend this to PRD, that would be new information and re-open this matter.

<sandro> Sandro: slotted terms in Core or not....?

<sandro> PROPOSED: Core will be what is currently called BLD with Equality removed, function terms removed, and perhaps safeness. We will not get rid of BLD. (Ignoring editorial issues for now) Frame are in Core, slotted terms are not.

<sandro> Harold: I think production rules need slotted terms.

<sandro> Harold: Clips has it.

<sandro> csma: we need to check this (whether production rules need slotted terms).

<Harold> http://en.wikipedia.org/wiki/CLIPS

<Harold> (deffacts trouble_shooting

<Harold> (car_problem (name ignition_key) (status on))

<Harold> (car_problem (name engine) (status wont_start))

<Harold> (car_problem (name headlights) (status work))

<Harold> )

<sandro> PROPOSED: Core will be what is currently called BLD with Equality removed, function terms removed, and perhaps safeness, and perhaps slotted terms. We will not get rid of BLD. (Ignoring editorial issues for now) Frames stay in core.

<sandro> RESOLVED: Core will be what is currently called BLD with Equality removed, function terms removed, and perhaps safeness, and perhaps slotted terms. We will not get rid of BLD. (Ignoring editorial issues for now) Frames stay in core.

<sandro> Chris: Now, how to document Core?

csma: we want to have a separate CORE document, so we can refer to it when we extend CORE but not BLD

<sandro> mk: If you want to know what Core is, read BLD or PRD, and then read what the subset is.

Michael: have two definitions of CORE - so don't need to read BLD defintion of CORE if working with PRD

csma (and Bob): we don't want to have two possibly conflicting defintions of CORE

<AxelPolleres> I'd like to paste here the most general definition of external predicates (built-ins), I know of (in an attempt to write down the definition of Eiter et al. in a RIF suitable way): an evaluable predicate &pred(X_1,....,X_n) is assigned with one or more binding patterns, where a binding pattern is a vector {in,out}^n. Intuitively, an evaluable

<AxelPolleres> atom provides a way for deciding the truth value of an output tuple depending on

<AxelPolleres> the extension of a set of input predicates and terms. Note that this means that

<AxelPolleres> evaluable predicates, unlike usual definitions of built-ins in logic programming,

<AxelPolleres> can not only take constant parameters but also (extensions of) predicates as

<AxelPolleres> input.

<AxelPolleres> i.e. inputs cannot only be terms, but also predicate names (in which case the extension of the respective predicate is part of the input). Such HEX-predicates (higher-order external predicates) have a fixed interpretation assigned. They are a very general way of evaluable predicates. THe distinction between input and output terms in binding patterns is made in order to guarantee that whenever all input values of a binding pattern are bound to concrete

<AxelPolleres> interpretation only allows a *finite* number of bindings for the output values, which can be computed by an external evaluation oracle.

<PaulVincent> Example OASIS XML rule language: http://www.oasis-open.org/committees/download.php/5929/CAM%20Technical%20brochure%2003Mar04.pdf

<PaulVincent> Example of readable XML format for rules: http://www.drrw.net/CAM/schematron/CAM-Schematron.htm

<AxelPolleres> scribe: Axel Polleres

<sandroPost> scribeNick: AxelPolleres

Action review.

http://www.w3.org/2005/rules/wg/track/

Action 152 - continued, new deadline: 2008-01-15

Action 172 - dropped (obsolete)

Action 173 - dropped

Action 212 - continued, new deadline: 2007-11-30

<Harold> Action 253 done: http://www.w3.org/2005/rules/wg/wiki/Arch/RIF_Components/RIF_Dialect_Structure

Action 253 - done, pending discussion.

csma: this is not what the action was about.
... action should be take current cond language, cut it to pieces.

Action 256 - dropped, subsumed by Sandro's activities.

Action 265 - dropped, subsumed by abstract model.

Action 274 - continued, should be reassigned, since unsure whether allen rejoins.

Action 292 - ...

chrisW: we wanted to add pointers to builtins in document, but still waiting for built-in definitions. - ... continued

Action 305 - done

Action 323 - done

Action 331 - done, still pending discussion.

Action 342 - done. Jos got reply's, they said we are basically on our own with both questions.

Jos: will summarize that thread and send a summary to the list.

<scribe> ACTION: jdebruij to send two mails on outcome of Action 342 [recorded in http://www.w3.org/2007/11/06-rif-minutes.html#action07]

<rifbot> Created ACTION-369 - Send two mails on outcome of Action 342 [on Jos de Bruijn - due 2007-11-13].

Action 346 - dropped

Action 349 - continued.

Action 350 - done, pending discussion.

Action 351 - done.

Action 353 - dropped

Action 354 - dropped

Action 358 - done

Action 359 - done, pending discussion.

ChrisW: Let's rephrase 359 to "Motivate Abstract Model for extensibility"

Action 361 - done, pending discussion. discussion yesterday, but still more discussion necessary.

Action 362 - continued

Action 363 - done

Actions 364, 365, 366 - continued

Action 367 - continued

Action 368 - done

Issues:

Issue 2 - ...

csma: Is this critical path?
... jos, please take an action to resolve that and look into the best practices document.

<scribe> ACTION: debruij to look into SW best practices document and draft a solution [recorded in http://www.w3.org/2007/11/06-rif-minutes.html#action08]

<rifbot> Sorry, couldn't find user - debruij

<scribe> ACTION: jdebruij to look into SW best practices document and draft a resolution for issue 2 [recorded in http://www.w3.org/2007/11/06-rif-minutes.html#action09]

<rifbot> Created ACTION-370 - Look into SW best practices document and draft a resolution for issue 2 [on Jos de Bruijn - due 2007-11-13].

issue 14 - ...

scribe: through Issue 21 are not critical path.

Issue 24 - is critical path.

Issue 25 - closed. Addressed by SWC document.

<ChrisW> PROPOSED: CLOSE ISSUE 25. Addressed by SWC document.

<ChrisW> RESOLVED: CLOSE ISSUE 25. Addressed by SWC document.

no objections.

Issue 26 - ...

sandro: could be discussed in testing. roundtripping could be in the testcases.
... not sure whether in a testcase document or in Arch.
... this is an open issue really.

csma: ... not out of critical path though.

Issue 27 - ...

scribe: not critical path.

<sandro> PROPOSED: close ISSUE-27 with the understanding that RIF Core will not have constraints.

<sandro> PROPOSED: close ISSUE-27 with the understanding that neither RIF Core nor RIF BLD will have constraints.

<sandro> PROPOSED: close ISSUE-27 with the understanding that neither RIF Core nor RIF BLD will have constraint logic programming.

<sandro> RESOLVED: close ISSUE-27 with the understanding that neither RIF Core nor RIF BLD will have constraint logic programming.

one editorial objection by bob..

Issue 28 - closed with earlier resolution on Core being basically datalog.

<sandro> PROPOSED: close ISSUE-28 with the understanding that RIF Core (as defined earlier today) does not have this problem.

<sandro> PROPOSED: close ISSUE-28 with the understanding that RIF Core (as defined earlier today) does not have the problems which caused us to raise this issue.

csma: background of this discussion was PRD discussion.

<sandro> RESOLVED: close ISSUE-28 with the understanding that RIF Core (as defined earlier today) does not have the problems which caused us to raise this issue.

no objections.

Issue 29 - ...

<sandro> PROPOSED: close ISSUE-29 with the understanding that the profile mechanism is being addressed elsewhere.

<sandro> PROPOSED: close ISSUE-29 with the understanding that the profile mechanism is being addressed elsewhere, and the idea of "profiles of Core" is handled by now having Core and BLD.

<sandro> PROPOSED: close ISSUE-29 with the understanding that the profile mechanism is being addressed elsewhere, and the issues around of "profiles of Core" are handled by having separate dialects, Core and BLD..

csma: this doesn't answer the question.

ChrisW: LEt's clos the issue when it is indeed addressed elsewhere.

csma: not critical path for BLD.

Issue 33 - critical path, not closed.

Issue 34 - on critical path ...

jos: is again accurate.
... not closed

Issue 35 - ...

jos: has now been resolved in the published WD.

<sandro> PROPOSED: to close ISSUE-35 with the understanding that this issue is settled in our latest published version of BLD.

no objections.

<sandro> RESOLVED: to close ISSUE-35 with the understanding that this issue is settled in our latest published version of BLD.

Issue 36 - ...

csma: what is the issue here?

ChrisW: open and critical path.

Issue 37 - not critical path, not closed.

ChrisW: why isn't it?

Sandro: Would that ever go in BLD?

Jos: We don't want to tie ourselved to having to address this.

ChrisW: nice to have, but shouldn't hold us.

Issue 38 - not critical path, not closed

csma: related to last one, but even less important.

Issue 39 - ...

jos: I'd say it is critical path.

csma: requirement in UCR.
... is critical path and open.

Issue 40 - ...

is critical path.

Issue 41 - is critical path.

scribe: and open.

Issue 42 -

sandro: I understood the answer from XML Schema to Jos as "you can do it, but we wouldn't recommend."

jos: let's discuss with Action...

csma: open and critical path.

Issues 43-45: critical path and open.

Issues 46 - not critical path, open.

scribe: phase open.

csma: let's check whether to assign actions to address the 11 critical path issues.

ChrisW: Let's move to Extensibility.

csma/jos: Can Issue-39 be quickly assigned?

scribe: not now.

csma: next points: next f2f, extensibility.

next f2f

sandro: first half of february preferred, not to lose pace.

csma: will check whether ilog can also make a proposal.

current proposals online: DERI Galway and JSI , http://www.w3.org/2005/rules/wg/wiki/F2F9

chrisw: prefer end of february, would maybe not be able to come first week.
... can definitly make it 26,27,28.

csma: proposal 1: 26/27, proposal 2: week 18-21

<scribe> ACTION: Christian to put f2f9 dates and proposals on agenda of telecon Nov 20th [recorded in http://www.w3.org/2007/11/06-rif-minutes.html#action10]

<rifbot> Created ACTION-371 - Put f2f9 dates and proposals on agenda of telecon Nov 20th [on Christian de Sainte Marie - due 1307-11-13].

sandro: Can start a Webform for preferred dates in february.

<scribe> ACTION: sandro to start a webform on preferred dates in feb for f2f9. [recorded in http://www.w3.org/2007/11/06-rif-minutes.html#action11]

<rifbot> Created ACTION-372 - Start a webform on preferred dates in feb for f2f9. [on Sandro Hawke - due 2007-11-13].

sandro: enter your preferences given that location will be in Europe.

<PaulVincent> scribenick: PaulVincent

<sandro> http://www.w3.org/2005/rules/wg/wiki/Arch/naf_example

More extensibility

Sandro: Topic = Extensibility
... extension example: add new condition type for NAF
... includes possible fallback options
... with XML spec defining comment, semantics, and RIF change
... and Fallback specification
... Applies to BLD and extensions (semantically ?)

Jos: need language to extend syntax

Harold: eg XSLT and XML

Jos: Who is target for extension format?

Sandro: All RIF processors

<AxelPolleres> Harold: What you were asking me is EXACTLY what I described in the AbstractModel document, and why I think that the abstract model is useful. It is just not being discussed.

Jos: Why need / how use a changelist?
... may be very complex

Sandro: Alternative is where extensions used are named...

<sandro> Sandro: Two Branches: (1) in the instance document, name each extension you use; (2) build schema for possible extensions and see which fit.

<sandro> if you have to name extensions, then you can't just combine the elements....

Jos: Danger of extensions being mutually exclusive
... and such docs should be rejected

Christian: Task of producer to use valid extensions/sets

Mike: Example case would be merging rulesets with different extensions

Axel: Modular extensions could be dangerous vs a new dialect

<MichaelKifer> scribenik: MichaelKifer

<MichaelKifer> csma: what do u do if u have to merge two documents coming from different dialects.

<ChrisW> Scribe: MichaelKifer

jos, axel: not clear how to do it. probably impossible. semantics may not be definable

sandro: want to add lists to PRD and BLD through the same extension mechanism

<sandro> Axel: if you have sound and complete fallbacks to two different dialects, then it's defined as if in a superdialect.

sandro: seems like the group thinks these ideas are interesting, but may be unworkable

will try to work on that more.

<sandro> Sandro: I think I know how to do the semantic independence from a programmers perspective, but I don't know the math side of it.

jos: major skepticism

<sandro> Gary: make it more fixed, eg TrimToRule, TrimToOr, TrimToAnd, ....

gary: reduce the scope of the extensibility mechanism

sandro: should design extensibility so that it itself will be extensible

chris to sandro: do u think every dialect will have the patience to describe itself wrt some smaller dialect?

csma: are we ready to make a resolution on extensibility?

<sandro> general consensus --- impact matrix is a good start

<sandro> general consensus -- trim to something is a good start

sandro: should we proceed developing the impact matrix?

gary: if a dialect decribes itself wrt a smaller dialect, what happens if the dialect(s) get updated?

sandro: I should work on an extensibility strawman

chris: try to do a fallback from bld to core

<AxelPolleres> I think we need some minimal RDF vokabulary to relate Dialects, a la: you can get from dialect A to dialect B via the following fallbacks... and fallbacks again being described by referencing a trasnformation, the impact, etc.

sandro: another one is extension of bld with equality, naf and lists

<sandro> ACTION: Sandro to write up strawman extension of Core to BLD. [recorded in http://www.w3.org/2007/11/06-rif-minutes.html#action12]

<rifbot> Created ACTION-373 - Write up strawman extension of Core to BLD. [on Sandro Hawke - due 2007-11-13].

<sandro> ACTION: Sandro to request extension to RIF charter [recorded in http://www.w3.org/2007/11/06-rif-minutes.html#action13]

<rifbot> Created ACTION-374 - Request extension to RIF charter [on Sandro Hawke - due 2007-11-13].

<sandro> PROPOSED: no invisible extensions

<sandro> PROPOSED: no invisible extensions (official or user extensions)

<sandro> Jos: exactly the same syntax, different semantics.

<sandro> mk: having a dialect tag is enough.

<sandro> axel: top-of-document tag or syntactic elements used -- either way.

<sandro> Chris: Issue -- what's the issue we use to make sure we avoid invisible extensions

<sandro> RESOLVED: no invisible extensions (official or user extensions)

<sandro> ACTION: Sandro to open the issue: how to make sure we avoid invisible extensions [recorded in http://www.w3.org/2007/11/06-rif-minutes.html#action14]

<rifbot> Created ACTION-375 - Open the issue: how to make sure we avoid invisible extensions [on Sandro Hawke - due 2007-11-13].

<sandro> cf top-of-document vs in-spot-of-use

<AxelPolleres> How to avoid invisible extensions: Whenever the intersection of your dialect with another dialect is non-empty, you have to make sure that your semantics coincides with that dialect on the intersection.

<AxelPolleres> That should be sufficient.

<sandro> yes, mechanically -- but the issue here is really "semantic flags at top of document"

<AxelPolleres> I don't like the top-level semantic tags, I think.

<sandro> me neither, but Jos and Michael do, and they're certainly more obvious.

<ChrisW> by next BLD WD: Resolve lists, meta-data, builtins, frames/classification

<ChrisW> ...and slotted uniterms

Michael: to make this feasible by mid December, peoplel should become more agreeable :-)

<ChrisW> PROPOSED: Be nice to Michael until december

<ChrisW> PROPOSED: Be nice to Michael until mid-december

<ChrisW> RESOLVED: Be nice to Michael until mid-december

<sandro> (so that he can produce strawman proposals as above. individual builtins handled by someone else.)

<ChrisW> ACTION: Christian to put on agenda the BLD plan [recorded in http://www.w3.org/2007/11/06-rif-minutes.html#action15]

<rifbot> Created ACTION-376 - Put on agenda the BLD plan [on Christian de Sainte Marie - due 2007-11-13].

<ChrisW> PROPOSED: Adjourn.

<ChrisW> RESOLVED: Adjourn.