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