RIF Face to Face Nov 6 2007 -- 6 Nov 2007

<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

<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 defautl 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 ell us what

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

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 a peice 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 incoroporate in only a 6 month time window

<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#action01]

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

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

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

<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: I will check this.

<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-predictes (higher-order externa 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 v

<AxelPolleres> intreatation 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

<AxelPolleres> Action review.

<AxelPolleres> http://www.w3.org/2005/rules/wg/track/

<AxelPolleres> Action 152 - continued, new deadline: 2008-01-15

<AxelPolleres> Action 172 - dropped (obsolete)

<AxelPolleres> Action 173 - dropped

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

<AxelPolleres> Action 253 - done, pending discussion.

<AxelPolleres> csma: this is not what the action was about.

<AxelPolleres> csma: action should be take current cond language, cut it to pieces.

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

<AxelPolleres> Action 265 - dropped, subsumed by abstract model.

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

<AxelPolleres> Action 292 - ...

<AxelPolleres> chrisW: we anted to add pointers to builtins in document, but still waiting for built-in definitions. - ... continued

<AxelPolleres> Action 305 - done

<AxelPolleres> Action 323 - done

<AxelPolleres> Action 331 - done, still pending discussion.

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

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

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

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

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

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

<ChrisW> ACTION: bruijn [recorded in http://www.w3.org/2007/11/06-rif-minutes.html#action04]

<rifbot> Sorry, bad ACTION syntax

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

<rifbot> Sorry, amibiguous username (more than one match) - jos

<rifbot> Try using a different identifier, such as family name or username (eg. jderoo, jdebruij)

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

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

<AxelPolleres> Action 346 - dropped

<AxelPolleres> Action 349 - continued.

<AxelPolleres> Action 350 - done, pending discussion.

<AxelPolleres> Action 351 - done.

<AxelPolleres> Action 353 - dropped

<AxelPolleres> Action 354 - dropped

<AxelPolleres> Action 358 - done

<AxelPolleres> Action 359 - done, pending discussion.

<AxelPolleres> ChrisW: Let's rephrase 359 to "Motovat Abstract Model for extensibility"

<AxelPolleres> Action 361 - done, pending discussion. discussion yesterday, but stil more discussion necessary.

<AxelPolleres> Action 362 - continued

<AxelPolleres> Action 363 - done

<AxelPolleres> Actions 364, 365, 366 - continued

<AxelPolleres> Action 367 - continued

<AxelPolleres> Action 368 - done

<AxelPolleres> Issues:

<AxelPolleres> Issue 2 - ...

<AxelPolleres> csma: Is this critical path?

<AxelPolleres> csma: jos, please take an action to resolve that and look into the best practices document.

<AxelPolleres> 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#action07]

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

<AxelPolleres> 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#action08]

<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].

<AxelPolleres> issue 14 - ...

<AxelPolleres> ... through Issue 21 are not critical path.

<AxelPolleres> Issue 24 - is critical path.

<AxelPolleres> 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.

<AxelPolleres> no objections.

<AxelPolleres> Issue 26 - ...

<AxelPolleres> sandro: could be discussed in testing. roundtripping could be in the testcases.

<AxelPolleres> ... not sure whether in a testcase document or in Arch.

<AxelPolleres> ... this is an open issue really.

<AxelPolleres> csma: ... not out of critical path though.

<AxelPolleres> Issue 27 - ...

<AxelPolleres> ... 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.

<AxelPolleres> one editorial objection by bob..

<AxelPolleres> 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.

<AxelPolleres> 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.

<AxelPolleres> no objections.

<AxelPolleres> 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..

<AxelPolleres> csma: this doesn't answer the question.

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

<AxelPolleres> csma: not critical path for BLD.

<AxelPolleres> Issue 33 - ciritcal path, not closed.

<AxelPolleres> Issue 34 - on critical path ...

<AxelPolleres> jos: is again accurate.

<AxelPolleres> ... not closed

<AxelPolleres> Issue 35 - ...

<AxelPolleres> jos: has now been resolved in the published WD.

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

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

<AxelPolleres> no objections.

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

<AxelPolleres> Issue 36 - ...

<AxelPolleres> csma: what is the issue here?

<AxelPolleres> ChrisW: open and critical path.

<AxelPolleres> Issue 37 - not critical path, not closed.

<AxelPolleres> ChrisW: why isn't it?

<AxelPolleres> Sandro: Would that ever go in BLD?

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

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

<AxelPolleres> Issue 38 - not critical path, not closed

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

<AxelPolleres> Issue 39 - ...

<AxelPolleres> jos: I'd say it is critical path.

<AxelPolleres> csma: requirement in UCR.

<AxelPolleres> ... is critical path and open.

<AxelPolleres> Issue 40 - ...

<AxelPolleres> is critical path.

<AxelPolleres> Issue 41 - is critical path.

<AxelPolleres> ... and open.

<AxelPolleres> Issue 42 -

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

<AxelPolleres> jos: let's discuss with Action...

<AxelPolleres> csma: open and critical path.

<AxelPolleres> Issues 43-45: critical path and open.

<AxelPolleres> Issues 46 - not critical path, open.

<AxelPolleres> ... phase open.

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

<AxelPolleres> ChrisW: Let's move to Extensibility.

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

<AxelPolleres> .... not now.

<AxelPolleres> csma: next points: next f2f, extensibility.

next f2f.

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

<AxelPolleres> csma: wil check whether ilog can also make a proposal.

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

<AxelPolleres> chrisw: prefer end of february, would maybe not be able to come first week.

<AxelPolleres> ... can definitly make it 26,27,28.

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

<AxelPolleres> 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#action09]

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

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

<AxelPolleres> 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#action10]

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

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

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 dsicussed.

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> Sandro: I want to be able to add List to PRD and BLD with the same extension.

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> Chris: Strawman --- Extension of Core to BLD

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

<sandro> Sandro: BLD to Equalirt, NAF, 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#action11]

<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#action12]

<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#action13]

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

to make this feasible by mid December, ppl 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#action14]

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

- DRAFT -

RIF Face to Face Nov 6 2007

6 Nov 2007

Attendees

Contents

Documents

next f2f.

Summary of Action Items

Scribe.perl diagnostic output