F2F9 Minutes

(Scribe changed to Axel Polleres)

Christian de Sainte Marie: objective is finishing BLD

... see agenda slides.

... next objective (if time) Core, PRD.

... agenda, see http://www.w3.org/2005/rules/wg/wiki/F2F9

Review of FLD+BLD reviews

Chris Welty: we start wih Igor's FLD review. http://lists.w3.org/Archives/Public/public-rif-wg/2008Feb/0048.html

Christian de Sainte Marie: XML serialization not present in the current draft. Do we want to publish without?

Harold Boley: I can easily add a paragraph.

Michael Kifer: in the next draft it will be extended.

Christian de Sainte Marie: maybe less critical, since we have XML in BLD.

... but we may get back to this in the extensibility discussion.

Sandro Hawke: the FLD document is not the right place, since this is only about logic dialects.

s/place,/place for the discussion of the XML syntax/ (failed)

Christian de Sainte Marie: comments on 2.0.2 alphabet ... done

... 2.0.4 Sigantures ... done.

... 2.0.5 ... done

... 2.0.6 Symbol Spaces: some discussion about why we don't support all XML schema types.

Michael Kifer: some discussion at last f2f with jos.

Jos de Bruijn: we didn't discuss what "supports" means. the problem is that we haven't clear here what/how to extend the basic datatyes to the reader.

Jos de Bruijn: suggest that we "support" all XML Schema types and "require" compliant engines to support a basic set.

Sandro Hawke: (Can you type in your concern?)

Harold Boley: How do we cross-reference to other W3C specs in general in general and in this case in XML Schema?

s/in XML/to XML/ (failed)

Jeff Pan: Some datatypes such as duration, entity are not realy "RDF-friendly"

s/realy/really/ (failed)

Chris Welty: How we came to our current list was that we wanted to suggest a core list for compliance and recommend support for all basic XML Schema types.

Jos de Bruijn: general confusion types that "RIF supports" vs. " are required to be supported by inference engines"

Michael Kifer: e.g. an engine that doesn't understand integer, but decimal would be able to deal with integers.

Christian de Sainte Marie: instead of making this subtle difference, would it be easier to define in geeneral that consuming engines translate datatypes in to their datatypes which have the same semantics?

Dave Reynolds: that's the implementers' business, has nothing to do with RIF compliance/compatibility

... why should RIF in the spec separate what is in the engine and in the language. what is in the engine is irrelevant, if the engine has to take care of the translation.

(hope I got that more or less right, dave)

Sandro Hawke: so if you support short and somebody adds 50000+50000 you are outside short, but not if you internally translate it to integer.

... but if our error semantics is that it is undefined how you handle errors than it would be ok.

Michael Kifer: maybe we should just delete the paragraph about what a RIF consumer engine is supposed to to about datatypes.

... the idea to put it in was to simplify the job of implementers

Jos de Bruijn: we don't really want to restrict the datatypes you are allowed to use, but we didn't want to impose all engine with the rif stamp to have to support all.

Christian de Sainte Marie: want to keep the paragraph.

Jos de Bruijn: also want to keep it.

Michael Kifer: RIF systems still have to support all the built-ins.

Jos de Bruijn: the problem at the moment is the (editorial) use of the words supports, compliant, consuming, etc. needs to be clarified.

MiachelK (guest): we could spell out subtypes.

Christian de Sainte Marie: remove "compliant" but only distinguish "producing" and "consuming" engines.

Michael Kifer: possibly break out datatypes in a separate document, at least keep the discussion on datatypes in one place... now scattered.

harold/michaelK: could be part of builtins document.

sandro/chrisw: Core document would make sense.

Chris Welty: paula was currently editor of builtins, but she is leaving the WG.

Harold Boley: I took over.

Axel Polleres: what should now be part of core and what of extensibility?

PROPOSED: Move text on datatypes and symbol spaces to Core

PROPOSED: Move text on datatypes and symbol spaces to Core

(some discussions on how to resize font on projector... ;-) )

Chris Welty: FLD covers a good part of what I understood was "arch"

... can we extend it?

Michael Kifer: easier to write something more specific.

Chris Welty: is there an active Core document.

Axel Polleres: no, because we stil discuss what should be in there.

s/discuss/need to discuss/ (failed)

Sandro Hawke: We need to clarify what core is actually gonna be.

Christian de Sainte Marie: definition od symbol spaces, datatypes in general belong to FLD.

... core supported datatypes in Core.

Michael Kifer: nothing depends on FLD, we have XML datatypes, etc.

Christian de Sainte Marie: how does putting the list of datatypes in Core make core dependent on FLD.

... and why is it a problem to depend on FLD, core IS a logic dialect.

Hassan Aït-Kaci: the documents are still too dense, we need some introductory document(s)

Sandro Hawke: not our job to explain it... others can write tutorials.

Gary Hallmark: testcases document would do a great part of that job already.

Chris Welty: it is more a question of bandwidth

Michael Kifer: we definitly need an entry-point document.

... a tutorial (as planned by harold,axel,me) is separate from that.

Adrian Paschke: add syntax to the use cases.

Christian de Sainte Marie: the style of syntax presentation at the moment is not the style which developers are used to.

(No activity for 13 minutes)

(No activity for 17 minutes)

(Scribe changed to Gary Hallmark)

FLD/BLD reviews, continued

issue (guest): RIF dialect can introduce new datatypes

spec should be clear that list of datatypes can be extended

Chris Welty: dialects must support AT LEAST the listed datatypes

Christian de Sainte Marie: come back to this issue when discussing extensibility

Chris Welty: what is a closed rif formula (in entailment section 3.0.7)?

Michael Kifer: no free vars

... entailment defined when no free vars (or implicitly universally quantified)

in BLD it is an error to have free variables (there is a resolution about this)

action on mkifer to forbid free variables

ACTION: Michael to make sure that BLD requires explicit quantification

ACTION: Mkifer to make sure that BLD requires explicit quantification

(No activity for 6 minutes)

ACTION: Mkifer to list FLD datatype subtypes explicity

rulesets should be explained earlier in spec because it is used to define scope of rif:local

ACTION: Mkifer to make sure "ruleset" is used consistently in FLD/BLD

define RIF-compliant processor

Christian de Sainte Marie: define compliant consumer/producer

Hassan Aït-Kaci: compliance is too strong a term

Sandro Hawke: we do mean compliance

Christian de Sainte Marie: "inference engine" is out of scope of definition

Sandro Hawke: need something specific like inference engine to define test cases

Christian de Sainte Marie: should focus on translation, not processing

Michael Kifer: compliance should go elsewhere

Jos de Bruijn: define compliance at dialect level

Michael Kifer: need to define generally what compliance means

... but it seems out of place in FLD currently

Michael Kifer: needs to be in Core

Chris Welty: realistically, will we have other docs?

... last call for BLD in 2-3 months

Michael Kifer: move datatypes, builtins, and compliance to another doc

Chris Welty: symbol spaces stays in FLD

Michael Kifer: can move symbol spaces too

PROPOSED: Create a new Document with provisional titles "Data Types and Builtins"

PROPOSED: Create a new Document with provisional titles "Data Types and Builtins"

PROPOSED: Create a new Document with provisional title "Data Types and Builtins" to contain elements common to all dialects

PROPOSED: Create a new Document with provisional title "RIF Vulgar" to contain elements common to all dialects

much discusson about possible title and content, including "RIF Core" (again!)

PROPOSED: Create a new Document with provisional title "Data Types and Builtins" to contain elements common to all dialects

PROPOSED: Create a new Document with provisional title "Data Types and Builtins" to contain elements common to all dialects with Harold and Axel as editors

Harold and Axel will edit the new document

RESOLVED: Create a new Document with provisional title "Data Types and Builtins" to contain elements common to all dialects with Harold and Axel as editors

ACTION: axel to create DT&B document by Friday

ACTION: mkifer to remove DT&B content from FLD

Michael Kifer: producer, consumer, etc. should be defined in a common place

... also notion of dialects

... overall processing model

... need a guide (overview) of all the docs

Christian de Sainte Marie: no time to create many new docs

Harold Boley: will we publish UCR?

Sandro Hawke: can do last call on UCR

Michael Kifer: I can write a 1 or 2 page overview (guide)

Sandro Hawke: can take BLD to last call without overview info

... sort of OK not to understand, as long as audience doesn't misunderstand

... sort of OK not to understand, as long as audience doesn't misunderstand

BLD reviews

Jos de Bruijn: need single defn of

... BLD

Christian de Sainte Marie: specialization of BLD from FLD should be appendix

Michael Kifer: direct (standalone) spec should be normative

Sandro Hawke: both can be normative

PROPOSED: make "specialization of FLD" sections (of BLD) appendices

PROPOSED: make "specialization of FLD" sections (of BLD) appendices, with both normative

PROPOSED: make "specialization of FLD" sections (of BLD) appendices, leaving standalone sections in place, and making both normative

PROPOSED: make "specialization of FLD" sections (of BLD) appendices, leaving standalone sections in place, and making both standalone and specialization normative

RESOLVED: make "specialization of FLD" sections (of BLD) appendices, leaving standalone sections in place, and making both normative

RESOLVED: make "specialization of FLD" sections (of BLD) appendices, leaving standalone sections in place, and making both standalone and specialization normative

ACTION: mkifer to move specialization sections to appendices

issue (guest): xml syntax is too loosely specified

Michael Kifer: what does loose mean?

Jos de Bruijn: presentation to xml translation table too informal

Christian de Sainte Marie: table is not enough

Jos de Bruijn: 2 issues: want self-contained description of XML and want better translation table

Christian de Sainte Marie: e.g. which elements are required, optional, etc.

Michael Kifer: but xml schema appendix gives more info

Christian de Sainte Marie: likes PRD style

Harold Boley: ebnf is precise

Dave Reynolds: my comments critique the xml schema, too

Dave Reynolds: most of my comments are relatively minor but are important to ensure interop

... distinguish between IRIs and CURIes

Dave Reynolds: why equality in rule bodies in CORE?

Michael Kifer: because it is easy if just in bodies

... sugar for equal(?x ?x)

Sandro Hawke: but what about classical negation and = ?

Jos de Bruijn: datalog + classical negation => disjunctive datalog

consensus is to remove equality from core to prevent problems with future extensions of core

Michael Kifer: to prove not(equal(1,3)) you must have such a fact

(No activity for 62 minutes)

(No activity for 9 minutes)

(No activity for 6 minutes)

(Scribe changed to Adrian Paschke)

SWC

Jos de Bruijn: Explains the four different entailment regimes fro RDF integration

Jos de Bruijn: Explains difference of OWL DL and OWL Full compatibility in RIF

Jos de Bruijn: a [p -> b]: p(a,b)

Jos de Bruijn: p might be a variable

Jos de Bruijn: interpretation of frames for the OWL Full compatibility workaround solution is different from the interpration in RIF FLD

Jos de Bruijn: a[p->b] <-> a[q->b]

Jos de Bruijn: i.e. q equivalent to p

Sandor (guest): distinguish the different interpretations of frames in RIF FLD and OWL compatibility also syntactically

Jos de Bruijn: RDFS: a sc b

Jos de Bruijn: RIF d [type -> a]

Jos de Bruijn: q[q->d] <- x [type -> b]

Jos de Bruijn: OWL DL: you can not use this rules anymore

Jos de Bruijn: In general frame syntax is incompatble from predicate syntax

Sandro Hawke: Expressions from OWL DL could be translated into both syntaxes

Sandro Hawke: How can you read it differently?

Jos de Bruijn: It is defined in the semantics

Sandro Hawke: We need something more concrete

Jos de Bruijn: I |= a[type -> b] if I |= b(a)

Sandro Hawke: How can this processed in the software

Jos de Bruijn: I imagine that somewhere in the rule set it is made explicitly

Jeff Pan: Why do we need to worry about rewriting a particular OWL statement

Jos de Bruijn: We don't rewrite

Jos de Bruijn: In RDFS the syntax can be frames

Jos de Bruijn: But in OWL DL they are classes

Jos de Bruijn: We want to use the same syntax for both

Jos de Bruijn: Use frame syntax as unifier

Jeff Pan: but you change the semantics

Jeff Pan: if you want to use different ontologies you will change the semantics

Harold Boley: we can use different way to write it syntactically

Adrian Paschke: if we are only talking about instance and subclass we can use a typed logic syntax

Chris Welty: the choices are binary predicate syntax or frames

Jos de Bruijn: then use onyl frames with different semantic interpretation

s/subcalls/subclass (succeeded, 7 lines ago)

Jos de Bruijn: BLD: I |= a[b->c] if <aI,cI> in Iframe (bI)

Jos de Bruijn: That is the semantics of BLD

Michael Kifer: Yes, it captures the meaning

s/Mikeal/Michael (succeeded, 1 lines ago)

Jeff Pan: I'm in favor of a syntactical destinction instead of a different semantic interpretation of frames when using OWL DL

Michael Kifer: The problem is with extensions

Michael Kifer: We wanted to stay close to first order

Michael Kifer: We need an explanation of frames in the OWL compatibiltiy section

Jeff Pan: Let the users define which sort of semantics they would like to go for

Jeff Pan: There is only one semantics for OWL DL

Chris Welty: no and OWL DL ontology can be also interpreted with OWL Full semantics

Jeff Pan: You can specify the semantics by an additional attribute

s/Jess/Jeff (succeeded, 1 lines ago)

Jos de Bruijn: Semantics is defined for the combinations

Jos de Bruijn: RIF-OWL Full; RIF-OWL DL

Chris Welty: You choose by using a tool

Chris Welty: You get potential different results depending which reasoner you use

Hassan Aït-Kaci: Think of Datalog and Prolog interpreters

bye Mike

Sandro Hawke: We can not solve this problems between OWL DL and OWL Full in our group

Chris Welty: Next step?

Jos de Bruijn: wether and how do we point to RDF graphs

Jos de Bruijn: which entailment regime to use

Axel Polleres: define imports of RDF data by using owl:import

reviews to RDF/OWL compatibility documents

Axel Polleres: Review of Axel

Axel Polleres: some editorial issues

Axel Polleres: imports of OWL ontologies

Axel Polleres: bi-directional or uni-directional imports

Chris Welty: it is reasonable that RIF can import anything

Axel Polleres: number 10 : example in section 2

Axel Polleres: number 11: is there a way to have it defined for standard RDF graphs instead of extende RDF graphs

Axel Polleres: make a distinction in the examples

(No activity for 11 minutes)

Axel Polleres: comment 22

Axel Polleres: do you get ill-typed literals with using RIF-RDF

Chris Welty: p(1). p(a). + (x,1) -> p(x)

Michael Kifer: that is not ill-typed

ACTION: Axel to do what he just said

ACTION: axel to make a strange use case to generate ill-typed literals

Axel Polleres: comment 24

Axel Polleres: comment 25

Axel Polleres: comment 26

Axel Polleres: comment 28: replace condition 4 by condition 4'

break!

(No activity for 22 minutes)

(No activity for 5 minutes)

ACTION: mkifer to move 2.0.9 to an appendix

PROPOSED: make argument names distinct

RESOLVED: make argument names distinct

if we don't enforce that RIF users always specifiy explicitly all the signatures of the public functions of a RIF rule set, named args are a good way to to make an "unkown" RIF rule set accessable to new users

if we simply skip them and don't implement them in the RIF XML schema it will be very hard for RIF users who need named arguments to extend the RIF schema with named arguments. But if we make them optional in the schema the users can choose if they need them or not

PROPOSED: We settled named arguments with: A RIF consumer that does not support named arguments MUST treat them as position arguments in the lexical order of the argument names (as pair of symbol-space name, and lexical representation of that order)

PROPOSED: We settled named arguments with: A RIF consumer that does not support named arguments MUST treat them as positional arguments (of a different predicate) in the lexical order of the argument names (as pair of symbol-space name, and lexical representation of that order)

PROPOSED: We settled named arguments with: A RIF consumer that does not support named arguments MUST treat them as positional arguments (of a different predicate, formed in a defined-by-BLD-way) in the lexical order of the argument names (as pair of symbol-space name, and lexical representation of that order)

PROPOSED: We settled named arguments with: A RIF consumer that does not support named arguments MUST treat them as positional arguments (of a different predicate, formed in a defined-by-BLD-way) in the lexical order of the argument names (sorted as a pair of symbol-space name, and lexical representation of that order)

PROPOSED: Removed named arguments.  :-)

PROPOSED: Make named arguments optional

PROPOSED: We settled named arguments with: A RIF consumer that does not support named arguments MUST treat them as positional arguments (of a different predicate, formed in a stable but implementation-dependent way) in the lexical order of the argument names.

PROPOSED: We keep named arguments, explaining in BLD that: A RIF consumer that does not support named arguments MUST treat them as positional arguments (of a different predicate, formed in a stable but implementation-dependent way) in the lexical order of the argument names.

+1 for Sandros proposal (Prova does not support named arguments anyway for efficiency reasons - and where I realy need them, e.g. in inductive logic programming, I simulate them via a meta programing interpreter)

PROPOSED: We keep named arguments, explaining in BLD that: A RIF consumer that does not support named arguments can implement them, with relative ease, by treated them as positional arguments (of a different predicate, formed in a stable but implementation-dependent way) in the lexical order of the argument names.

(Scribe changed to Jeff Pan)

Chris Welty: let's describe how easy it is in the doc, since MichaelK said it is easy

Michael Kifer: My only concern is that whether it is be in the main part of a document or in an informative appendix

Chris Welty: it should not only be in examples, it should be in spec

Sandro Hawke: why does it affect comformance, ChrisW?

(ChrisW has to go)

Christian de Sainte Marie: we might need to write implementation hints in some of the docs

PROPOSED: We keep named arguments, explaining in BLD that: A RIF consumer that does not support named arguments can implement them, with relative ease, by treating them as positional arguments (of a different predicate, formed in a stable but implementation-dependent way) in the lexical order of the argument names.

s/treated/treating (succeeded, 1 lines ago)

Christian de Sainte Marie: we close Issue 44

PROPOSED: We keep named arguments, explaining in BLD that: A RIF consumer that does not support named arguments can implement them, with relative ease, by treating them as positional arguments (of a different predicate, formed in a stable but implementation-dependent way) in the lexical order of the argument names. (Closing ISSUE-44)

RESOLVED: We keep named arguments, explaining in BLD that: A RIF consumer that does not support named arguments can implement them, with relative ease, by treating them as positional arguments (of a different predicate, formed in a stable but implementation-dependent way) in the lexical order of the argument names. (Closing ISSUE-44)

abstain (guest): josb, DaveR, GaryH

Christian de Sainte Marie: why can a term be a frame?

... why did we change from only counting const, var and func as terms?

Michael Kifer: once the framework is there, all this becomes possible

... in the new version, the semantics is simpler in some sense

... now a(b->c(d->e)) is no longer the same as a(b->c) ^ c(d->e)

... now the whole term c(d->e) is the value, rather than c is the value

... the new semantics allows reifications

Christian de Sainte Marie: what is the consequence when you use frames

Sandro Hawke: how about variables?

Jos de Bruijn: why to make the language more complex?

Michael Kifer: the language is the same

jobs (guest): allowing equalities and frames as terms makes the language more complex

PROPOSED: equality, frames, subclass, membership are not terms in BLD

Sandro Hawke: agree with csma and josb

Christian de Sainte Marie: this is a major change in BLD

Harold Boley: the reviewers were fine with it

Christian de Sainte Marie: maybe people overlooked it

... we should ask the reviewers

Christian de Sainte Marie: what's DaveR's opition?

Dave Reynolds: I missed that

... the new approach does seem to be a worry for me

Christian de Sainte Marie: being in the framework is different from being in BLD

Michael Kifer: a=(b=c) does not entail b=c

PROPOSED: equality, frames, subclass, membership are not terms in BLD

PROPOSED: equality, frames, subclass, membership are not terms in BLD

Michael Kifer: I just want to make it clear, don't have problem disallowing them in BLD

... in BLD many good things don't make much sense

Michael Kifer: it wont be back to the last version due to nesting

... I agree that BLD should be simple

... a group is needed to have a dialect extending BLD with reification

... with reification the semantics is simpler

PROPOSED: No reification in BLD. This is like WD1, except no nested frames. A change from 18-Feb draft: Equality, frames, subclass, membership are no longer terms.

RESOLVED: No reification in BLD. This is like WD1, except no nested frames. A change from 18-Feb draft: Equality, frames, subclass, membership are no longer terms.

2 abstain

bye, Dave

(No activity for 11 minutes)

(No activity for 23 minutes)

(No activity for 867 minutes)

(No activity for 6 minutes)

(Scribe changed to Michael Kifer)

Action 292: Axel+Harold take over

(No activity for 9 minutes)

Action 373: to be discussed this afternoon

Action 375: dropped

s/scribenik/scribenick/ (failed)

Action 382: to be discussed this afternoon

Action 384: keep open (reincarnated as aggregates)

Action 404: handle off-line

Action 405: this afternoon

Action 407: closed

Action 411: closed

Action 413: this afternoon

Action 419 - 422: closed

Action 423: Axel+Harold - generic syntax of builtins; 2 weeks

breakouts (guest): builtins/datatypes, error handling, PRD,

(No activity for 5 minutes)

(Scribe changed to John Hall)

Sandro Hawke: no pint in using model theoretic structures

Christian de Sainte Marie: what is best way, given target audience?

Adrian Paschke: can at least describe language in first order

Christian de Sainte Marie: my first question

Gary Hallmark: will developers want to read BLD

Gary Hallmark: developers will need more tutorial material

Gary Hallmark: wouild like to see us in same positions as BLD

Christian de Sainte Marie: disagrees, developers want to see schema and be told how it works

Christian de Sainte Marie: most people in PR environment are developers

Christian de Sainte Marie: would be worried to have presentation that is too formal

Christian de Sainte Marie: unambiguous, concise, normative, easy to undersstand, as for BLD yesterday

Gary Hallmark: problems with consistency with different presentations

Gary Hallmark: consistent and wrong better than correct and inconsistent?

Gary Hallmark: should look like it was all designed with big picture

Christian de Sainte Marie: easy step - overlap, same BNF

Christian de Sainte Marie: would work with grammar rather than presentation syntax

Gary Hallmark: want non-trivial common core, maybe PR programmer has to learn it

Christian de Sainte Marie: who will make decision that PRD is format to adopt

Gary Hallmark: business people

Christian de Sainte Marie: not here, business people will ask programmers

Gary Hallmark: only ILOG?

Christian de Sainte Marie: ILOG, Fair Isaac and JBoss covers what ILOG marketing dept cares about

Adrian Paschke: risk of ambiguity

Christian de Sainte Marie: can be unambiguous without being formal in math sense

Christian de Sainte Marie: we disagree, but we could try a better way, err on the formal side?

Gary Hallmark: PR engines disagree on transition rules

Christian de Sainte Marie: would be easy to change the (small) parts that are about states and transitions

Christian de Sainte Marie: another thing, if built-ins and data types are in new document - do not have to explain here

Gary Hallmark: Harold's idea to reuse syntax would be valuable

Christian de Sainte Marie: syntax would be easy to extract to use in different documents

Christian de Sainte Marie: but architecture is moving towards self-contained documents

Sandro Hawke: if core is part of BLD that PR vendors can implement, PR vendors should be able to read BLD, then PRD for small additions

Sandro Hawke: PRD - syntax of retract, and here's what happen when you retract

Christian de Sainte Marie: preference would be to read PRD without having to read Core, then final section points to subset that can be interchanged

Christian de Sainte Marie: as a specifier, other may work better

Sandro Hawke: PR vendors should understand Core

Christian de Sainte Marie: two ways - by itself, or as a subset of PRD

Christian de Sainte Marie: developers will probably develop from tutorials, books, etc. - not from spec

Christian de Sainte Marie: from F2F8, reference manual style was preferred

Christian de Sainte Marie: include by reference built-ins, data types, syntax ...

Gary Hallmark: only syntax is needed

Gary Hallmark: will not agree on semantics, but will on test cases

Christian de Sainte Marie: extract from PRD, remove negation, aggregation and all actions but Assert

Gary Hallmark: add Retract and semantics will break

gary; add priority and retract

Christian de Sainte Marie: did not suggest that we will have a model theory

Christian de Sainte Marie: operational semantics of PRD, includin retract, negation

... write rules that contain only Assert

... will bet the same fact base as for Core

gary; how does that help?

Christian de Sainte Marie: one way - take Core and add those constructs (with semantics) and agree on Core. Do not re-decribe core.

... other, re-describe Core in PRD style

... from spec viewpoint, first way is best, and is preferred in this group.

Christian de Sainte Marie: propose to leav aggregation for the moment, but include negation

Christian de Sainte Marie: already a big risk that we are dismissed as semantic web people

Gary Hallmark: but we have to start somewhere with something that is usable

Christian de Sainte Marie: use NAF because it seemed acceptable in Boston

... leave aggregation, include Core by reference

Gary Hallmark: just the syntax?

Christian de Sainte Marie: probably agrees with what I meant by 'overall semantics'

Christian de Sainte Marie: if we start from assumption that we have is correct but less than useful, we have a specification

... the problem is to present it in a way that is precise and easy to read

Christian de Sainte Marie: so rewrite according to this discussion, leave out aggregation, but include retraction and negation

Gary Hallmark: is hard to follow, like a long proof without a summary up front

Christian de Sainte Marie: 'data source' went to 'WM'

Gary Hallmark: missed that

Christian de Sainte Marie: should change name of WM, and separate built-ins and data types

Christian de Sainte Marie: which formalisms to use? Plotkin, others?

... but use one that exists, don't invent a new one

Christian de Sainte Marie: can float a new version before OMG meeting (Mrach)

Mrach - March

Christian de Sainte Marie: minimum is that it agree with Core on subset of syntax

Christian de Sainte Marie: how far do we allow flexible, idiosyncratic representations?

Christian de Sainte Marie: order to fire rules, how to control loops ... lost of small differences

Gary Hallmark: can compare how systems (as represented in same formalism) work, then look at how to reconcile

Christian de Sainte Marie: this (hard) part is not in current draft

Gary Hallmark: but is what we have to address

Christian de Sainte Marie: work done in Core and BLD has helped in developing PRD

... showing where we have to focus

Gary Hallmark: there is no agenda for this (transition, etc)

Christian de Sainte Marie: should start discussion by emial, focused on appraoch

emial - email

Christian de Sainte Marie: What is approach - does RIF include specification language or not?

Christian de Sainte Marie: need to start by understanding the major differences

... one - essential for ILOG, FI, JBOss that RIF addresses a significant part of theur legacy

Gary Hallmark: but your legacy should not be forced on to me

Christian de Sainte Marie: did not say that but for example 'else' should be handled even if not in RIF

... have to have recursive condition, or move it all into the 'if'

(No activity for 18 minutes)

(No activity for 20 minutes)

(Scribe changed to Harold Boley)

Chris Welty: Prefers appr. 3

... Hassan not to lock into one appr. (abstain).

... Jos: 2

Michael Kifer: torn between approaches.

Christian de Sainte Marie: Implementation-dependent?

Michael Kifer: no.

Sandro Hawke: How to guard overflow?

Hassan Aït-Kaci: fail or error?

Chris Welty: Either we model what happens or we handle it outside.

Sandro Hawke: Not what systems really do.

Michael Kifer: Arbitrary precision arithmetics can also not really be implemented.

Sandro Hawke: easiest case: divide by zero.

Harold Boley: Approach 2 looks unsound. Appr. 3 is most 'neutral', so favor it.

... huge amount of work, e.g. in algebraic data types: let's be careful not to reinvent the wheel.

Christian de Sainte Marie: Coming back to divide by zero example:

... XPath F&O says something here.

... Gives C Error Summary

Chris Welty: But doesnt have a model theory.

Michael Kifer: We cannot rely on 'the other side'.

... RIF cannot guarantee that results on both sides are the same.

Christian de Sainte Marie: OK, but we cannot just import from X F&O.

Axel Polleres: Solution to introduce a predicate to test if an error might have occurred.

Jeff Pan: Unlike for real computer systems, for reasoners it's not so dangerous if divide by zero example occurs

Michael Kifer: If we adopt appr. 2 we need to have everyone adopt our exact semantics.

... Thats why appr. 3 is more acceptable.

Hassan Aït-Kaci: Distinction betw. model theory (where it is false as argued by Jeff), but there is also an operational meaning, which signals that something is wrong.

Michael Kifer: If I dont use guards, things go wrong.

(Scribe changed to Harold Boley)

Chris Welty: Hear majority seems to favor appr. 3

... all mappings are total.

Michael Kifer: Still true or false.

Hassan Aït-Kaci: Three possible outcomes. Two values. False w/o error, False w error, True.

Jeff Pan: May break fixed interpretation.

Michael Kifer: RIF-compliant systems must decide.

Jeff Pan: RIF would not require implementations to have fixed interpretations.

Michael Kifer: Ok, but would not tell you which one.

... practically better: when you transmit rule set, guaranteed that receiver will have exact same answers.

... if not you have no way of knowing what other system would do.

Jeff Pan: What are guards here?

Michael Kifer: E.g. is-integer, is-string

... they are (testing) builtins.

Hassan Aït-Kaci: Burden would be shifted on users, who would need to pre-edit their rule sets.

Chris Welty: We can only choose between appr 2 and appr 3 because of time restrictions.

Show of hands:

appr 2:

0

appr 3:

8

No objections against appr 3.

PROPOSED: BLD Spec does not require that builting predicates return F on error, just that they have a truth value. BD spec recommends using guards with builtins, to give predictability. Without guards, rules may behave unpredictability.

s/0/2/ (failed)

PROPOSED: (Approach 3) Function on error return an error element that is in the domain. BLD Spec does not require that predicates return F on error, just that they have a truth value. BD spec recommends using guards with builtins, to give predictability. Without guards, rules may behave unpredictability.

PROPOSED: (Approach 3) Function on error return an error element that is in the domain. BLD Spec does not require that predicates return F on error, just that they have a truth value. BDL spec recommends using guards with builtins, to give predictability. Without guards, rules may behave unpredictability.

Axel Polleres: Guards are type-checkers.

No objections

RESOLVED: (Approach 3) Function on error return an error element that is in the domain. BLD Spec does not require that predicates return F on error, just that they have a truth value. BDL spec recommends using guards with builtins, to give predictability. Without guards, rules may behave unpredictability.

Builtins

(Scribe changed to Harold Boley)

Axel Polleres: Reports from Types and Builtins breakout session.

... There is no op namespace definition.

Sandro Hawke: We can define rifop.

Axel Polleres: We would not define op:Equal, op:dayTimeEqual, ... but define it generically.

... as in SPARQL.

... (overloading)

... Just want generic less-than.

... Not have four versions, all to be mentioned in a rule (or four rules).

Sandro Hawke: First impression: keep original X F&O names, even if less generic.

... (basic ones)

Jos de Bruijn: Against doing everything generically -- e.g., not require everyone to implement boolean-less-than

ACTION: sandro to request 2008/xop or whatever for F&O op

Axel Polleres: Current list of builtins is missing some ops.

Christian de Sainte Marie: It should be a non-controversial list.

ACTION: axel to propose list of builtins including type checking and casting

Harold Boley: Will come back to syntax (e.g., ExtTerm, Extterm, Exterm).

ACTION: michael to add builtins to semantics of BLD and FLD

ACTION: mkifer to add builtins to semantics of BLD and FLD

Axel Polleres: Guard, Cast, ...

Gary Hallmark: is-not-string etc. would be good.

... for all guards.

Harold Boley: Special kind of negation.

Harold Boley: What after flattening to And( ?x= +(a,1) isNotString(?x))?

Michael Kifer: isNotString(?x) is equivalent to And(Not(isString(?x)) Not(isError(?x))).

Gary Hallmark: W

hat about having two predicates: isError and isNotError.

Chris Welty: agrees.

Jos de Bruijn: We dont want people to start 'programming' with these predicates.

Hassan Aït-Kaci: How many people will use this setup.

Michael Kifer: You dont NEED to use it.

Jeff Pan: How does it work.

Michael Kifer: It's like try-catch.

... has model theory.

Gary Hallmark: Need not be done in the expression tree, can be done at its root.

Harold Boley: Agree, dont want this proliferation of builtins.

Adrian Paschke: Think of later extensions by new positive builtins: negative ones will also need to be added.

Michael Kifer: Simpler to duplicate the builtins.

... isNotError(err) returns false.

Adjurn until 2PM.

(No activity for 48 minutes)

(No activity for 45 minutes)

(Scribe changed to Hassan Aït-Kaci)

Discussing forward compatibility of BLD - what should implementers need to know

the "traditional" way is to ignore what they need and provide extensions they need

"features", such as equality and named args, would be specified per variation of a dialect departing from BLD

XML annotations tags could be used to specified the features in a "a la carte" fashion to create an extension of BLD

s/annotations/annotation/ (failed)

If a feature is not implemented, some transformation is applied and comments/tags included to mention that fact (e.g., if named args are not implemented, they are transformed as positional and comments are generated saying so

s/saying so/saying so)/ (failed)

s/tags /tags are / (failed)

Sandro keeps on describing his transformation scheme to adapt missing features into others supported

This is "poor man" fallback mechanism could be used to specify how to adapt missing features using existing ones

s/This is/This/ (failed)

This mechanism could be a preprocessor or a filter

Chris Welty: will this part of the specs?

Sandro Hawke: non-normative, perhaps...

Christian de Sainte Marie: The specs should define RIF Core so as anything that is not in it be rejected (using Sandro's device)

Questions (guest): what does 80% sound mean?

Sandro Hawke: this is based on the level of severity (i.e., ignore, warning, error)

Jos de Bruijn: then this should not be soundness but completeness

Sandro Hawke: the mechanism is there to allow degrees of severity

Sandro Hawke: the intention is to "minimize" some overall severity level by composing them

Gary Hallmark: I doubt that BR people would be happy to see their rules changed behind their back - they would rather do this sort of things themselves - not the machine

Sandro Hawke: the spec say what features should or must be there; and some graceful fallback mechanism

Chris Welty: So what do we do?

Sandro Hawke: XTAN (XML Transform As Needed) can be a tool on its own (not just for RIF)

Sandro Hawke: I.e., a specific document should describe it

(Scribe changed to John Hall)

(Scribe changed to Axel Polleres)

(Scribe changed to Axel Polleres)

Harold Boley: finitelty nested functions can be translated to Datalog.

... if nesting depth can be limited.

(we have a corporate rate of 89 EUR from NUIG at westwood hotel BTW, for f2f10)

jos/michaelK: discussion naming uniterms vs atomic formulae

I am lost!!!!

3 strands of discussion going on.

Jos de Bruijn: problems with functions predicates uniterms.

josb/sandro: make explicit in the syntax

Christian de Sainte Marie: context not enough to decide?

michealK (guest): I find it srange just to make changes just to make it easier to implement a certain tool.

Jos de Bruijn: it is confusing because all is a term.

Chris Welty: it can stil look the same but we can call the syntactic construct

... in the syntax tree different

s/term/construct (succeeded, 2 lines ago)

Harold Boley: we have this since years and now and it passed many reviews.

... will not chang it because one python tool doesn't work.

... prolog and f-logic tools like Flora have this implemented.

Jos de Bruijn: that's not the point. a pred is a pred a func is a func.

Axel Polleres: not the same for a prolog programmer who think in terms of functors

gary, chrisw: doesn't affect the language, just the grammar.

Christian de Sainte Marie: we can make the move without loosing anything.

Harold Boley: FOL is too restrictive for the SW.

Axel Polleres: the uniterm stuff also caused difficulties for the metamodel attempt which I did.

it shouldn't make a differnce to name them differently.

Michael Kifer: it is basically a change of grammar only, I agree.

Harold Boley: you also change the mathematics.

miachaelK (guest): slight chane in the english description and the grammar necessary, not more.

ChrisW going to paint something on the flipchart.

Adrian Paschke: in favor of uniterm.

Adrian Paschke: uniterm more clear than "function"

Chris Welty: there was a change from compaund to uniterm yesterday

Harold Boley: ... as it used to be.

Christian de Sainte Marie: no, COMPOUND stays there.

Christian de Sainte Marie: we replace compound by uniterm.

... in terms

Chris Welty: ho to distinguish funcrtions from predicates.

jos running faster than gary to write the solution on the whiteboard

Harold Boley: In the first section of BLD we often talk about Terms, where uniterms are referred.

... we need to change it.

Jos de Bruijn: not one word needs to change.

Gary Hallmark: we didn't get rid of uniterm, it is still there, but with two concrete distinctions.

Michael Kifer: Ideally we should have one gorund for the BNF and one for the XML.

Sandro Hawke: one schema for all RIF? and then specializations for BLD, Core, PRD, etc.?

Michael Kifer: we need to work it out, don't know if it is possible. but maybe to early for the BNF to change it now.

Christian de Sainte Marie: if we start something that's shaky now, we put WD2 at risk

Sandro Hawke: I undserstand it is a lot of work.

Jos de Bruijn: i don't

Chris Welty: it is not about that change, but on whether int terms of a more severe change on the framework, it is useful to change the bnf now, which will change anyway later on for the framework.

Michael Kifer: let's wait for the framework to change the bnf adhoc now.

s/to change/instead of changing/ (failed)

Sandro Hawke: framework is not critical path and a new XML syntax will take at least a day in f2f to get it through

... puts wd2 at risk.

Jos de Bruijn: there is a clear distinction between atomic and functions in FLD document.

... it is very unlikely that we need to reverse anything if we do this change now.

harold explaining what he just pasted in the IRC.

s/[R,S]/(R,S)/ (failed)

josb/MichaelK discussion how to specialize BNFs.

Axel Polleres: would be easy with an abstract model instead :-)

Jos de Bruijn: I can do the BNF change.

Harold Boley: No, we could do it, but we need to think about it.

Michael Kifer: I don't want to do it for the WD because there is no rush. Proposals should be made explicit and discused for the next draft.

Jos de Bruijn: will make a proposal for the BNF for telecon in a week and a half.

ACTION: jdebruij2 to create a new BNF for FLD and BLD (distinguishing atoms and preds) by Monday 3rd of March

(BREAK)

TestCases

scribnick (guest): AdrianP

(Scribe changed to Adrian Paschke)

RIF Test Cases

Sandro Hawke: shows test case on the WIKI

}

ACTION: jeffp to post test cases for RIF

ACTION: jpan2 to post test cases fir RIF

ACTION: AdrianPaschke add some test cases to the WIKI page

ACTION: adrian paschke add some test cases to the WIKI page

ACTION: apaschke add some test cases to the WIKI page about test cases

ACTION: hboley add IRIs to presentation syntax

ACTION: Harold2 Make proposal for adding metadata into BLD syntax.

ACTION: Harold4 Make proposal for adding metadata into BLD syntax.

ACTION: Harold Make proposal for adding metadata into BLD syntax.

(No activity for 7 minutes)

(No activity for 5 minutes)

(No activity for 5 minutes)