W3C

- DRAFT -

F2F3 9 Jun 2006 Session 1

9 Jun 2006

See also: IRC log

Attendees

Present

Regrets

Chair
Chris Welty
Scribes
igor, David Hirtle, Micheal Kifer, MarkusK

Contents


<scribe> scribenick: igor

Formal semantics

(on-screen: slide 4 of http://www.w3.org/2005/rules/wg/wiki/F2F3?action=AttachFile&do=get&target=Goals%2C+CSF%2C+Requirements+%28final+version%2Blinks+to+minutes%29.ppt)

Phase 1: clear and precise semantics.

multiple semantics

(slide 5)

<sandro> WG charter phase 1 -- http://www.w3.org/2005/rules/wg/charter#phase_1

<AxelPolleres> In case that someone on the phone wants to speak, please let us know on IRC, we have to switch on a microphone manually in case.

Sandro: multiple semantics

<sandro> necessary to understand in phase 1

JosB: phase 1 has to cater for multiple semantics for phase 2

Markup of semantics

(slide 6)

Phase 1. RIF should have a standard way to specify the intended semantics (or style) of the rule set in RIF

meta language features

(slide 7)

ChrisW: meta language features - phase 2

csma: make two requirements

<sandro> difference between tags like priorities and authors -- meta data vs meta reasoning

hassan: move it into previous requirement

<sandro> Sandro: we need meta data, not meta reasoning, and priorities/preferences are part of the language.

chrisw: add a new requirement on meta data

<sandro> ACTION: Sandro to make sure the Requirements in Charter Phase 1 are in the Requirements Draft, or discussed in WG. [recorded in http://www.w3.org/2006/06/09-rif-irc]

proposed: meta language features go into RIFRAF

<sandro> Mike, are you generally hearing us well this morning, with our table mics?

meta rules for meta reasoning goes into Phase 2 and RIFRAF

<mdean_home> yes - it's a lot better than yesterday

meta data

(slide 8)

Meta data like author, rule name, is Phase 1.

RIF should support first order deductive rules

(slide 9)

MichaelK: normative rules are in general any formulas, not just rules

chrisw: deductive rules (partially) go into Phase 1
... normative and reactive go into Phase 2

sandro: some normative rules may be covered in phase 1

<sandro> The term "Horn Logic" in the Charter is ambiguous about whether it includes Normative Rules. "Positive Horn" does not, and is the normal use of "Horn".

PaulV: we need to specify phase 1 target before ruling out languages
... which go into phase 1 or phase 2
... the phase 1 goal is to interchange fragments of languages

<sandro> ChrisW: Phase 1 Goal == Interchange the Horn Fragement of existing Rule Languages

<scribe> ACTION: Paula clarifies which deductive rules exactly what goes into phase 1 and what into phase 2 [recorded in http://www.w3.org/2006/06/09-rif-irc]

<pfps_home> I still don't understand why Phase 1 has to cater to multiple semantics

<pfps_home> (I didn't mean to put the question to the entire group, just to Jos)

<scribe> ScribeNick: David Hirtle

RIF should support prolog-like rulesets

(slide 10)

dropped

RIF should cover production rules and ECA

Phase 2 ==> RIFRAF

<sandro> anyone on the phone?

<sandro> (awake)

<scribe> ACTION: Paul to clarify what part of production rules can be usefully translated using phase 1 RIF

<pfps_home> I could be on the phone, but it is a bit involved from home.

combined rulesets

(slide 11)

<sandro> pfps_home, I was just curious about whether ChrisW could be heard -- and if anyone cared.

(we have more microphones today)

<pfps_home> OK, I'll check the sound situation out.

<sandro> pfps_home, if you're not listening it doesn't really matter if you can hear us. :-)

<pfps_home> Wow, Zakim remembers from years ago!

ChrisW: if all horn clauses mean the same thing, this is irrelevant for phase 1

<pfps_home> Sound is much better than yesterday (modulo the occasional burst of noise).

csma: I still don't understand what this means exactly

paula: some rule languages have both deductive and reactive rules, for example

csma: then this is RIFRAF & Phase 2

(slide 12)

support rulesets with features from multiple languages: DROPPED

<pfps_home> Some people are very clear, as usual Chris is not so clear. :-)

(he doesn't always get the mic up to his mouth)

<sandro> Chris is standing and keeps dropping his hand holding the mic

<sandro> we should get Chris a lapel mix

<sandro> we should get Chris a lapel mic

<pfps_home> In general, only loud speakers come through - I think that the "cutover" level is set too high.

<pfps_home> I can hear the background hiss cutting in and out when the sound level is too low.

RIF rules should be ale to call out to external query processors

(slide 13)

sandro: charter mentions arithmetic builtins

dave: that might do

sandro: we have to demonstrate extensibility, but not sure about phasing

dave: the mechanism is probably phase 1, the core set is phase 2

sandro/csma: not required by charter in phase 1

chris: so it's phase 2 but we may do it earlier

RIF should support uncertain and probabilistic information

(slide 14)

chris: phase 2

RIF should support typed languages

(slide 15)

hassan: phase 1

<sandro> csma reads http://www.w3.org/2005/rules/wg/charter#datatype0

sandro: charter says nothing about typed variables

<sandro> Difference between typed data values and type-constrainted varaibles

<pfps_home> How do production rules *need* typed variables - OPS rules don't have them, I think. This is not to say that certain rule systems don't have them, just that some don't.

sandro: don't see why this is phase 1

<sandro> sandro: why are typed variables in phase 1?

<sandro> hassan: you can transform types into predicates

<sandro> sandro: right

csma: does Horn preclude types?

<AlexKozlenkov> Horn does not preclude typed variables

<pfps_home> Extensions of Horn could easily include typed variables.

<AlexKozlenkov> Prova uses typed variables in derivation and reaction rules

csma: we can choose whether we support types in phase 1 or phase 2

harold: we can regard it as a syntactic extension

<sandro> syntactic sugar

sandro: I think types are really useful

dave: let's phrase it so we know it's just syntactic sugar

<AlexKozlenkov> A simple example <Var typesystem="Java" type="java.lang.Integer">I</Var>

<pfps_home> I don't understand why an interchange format should *ever* have syntactic sugar - syntactic sugar is designed to make things easier for people to see, and this is not a forcing function for interchange langugages, which are not designed for human consumption.

<AlexKozlenkov> agree, pfps

<bonatti> if syntactic sugar allows for shorter messages, then it is good for an interchange format

<sandro> pfps_home, one reason: because you want to round-trip through the RIF without losing the structure that people/systems find useful.

<AlexKozlenkov> typed variables is not syntactic sugar

<bonatti> I agree

<pfps_home> Isn't XML a counterexample against short interchange formats?

<bonatti> is XML good?

<AlexKozlenkov> one could have different type systems

<pfps_home> But syntactic sugar is not a good thing for preserving structure, because it is so easy to flip between the sugar and the base.

<sandro> csma: we dont want to force translators to de-sugar types, in phase 1

chris: who wants this in phase 1?
... otherwise, it's phase 2

<sandro> ChrisW: resolved it's phase 2, for lack of a champion in phase 1

<sandro> csma: note that it can still be done in Phase 1, we're just not requiring it.

support oracular models

(slide 16)

chris: is this different than an external call?

dave: it seems frank (who originally posted this) thought it was the same thing
... because he replied to my email about external calls with "that's already there"

harold: it's just the wrong thing to call it oracular

csma: replaced by "external calls" requirement

extensibility of semantics markup

(slide 17)

chris: phase 1
... whose requirement is this?

csma: requires clarification

sandro: I'd be happy to drop this

chris: like last one, this needs a champion otherwise it'll go away

<sandro> "this" is slide "Extensibility of Semantic Markup"

csma: dropped because covered under the CSF of extensibility

sandro, not the whole requirement, just the slide?

<sandro> DavidHirtle, um not sure, since I don't know what requirement corresponded to that slide

conformance model

(slide 18)

chris: phase 1

(break time)

<sandro> Sandro: I'm am okay (if not happy) with dropping my Soundness requirement in favor of the more general "default behavior" requirement

<AlexKozlenkov> sound is completely gone now

<sandro> We're on break.

<sandro> scribeNick: MichaelKifer

<AxelPolleres> In case that someone on the phone wants to speak, please let us know on IRC, we have to switch on a microphone manually in case.

should be possible to build reasoners for intended rulesets languages without unnecessary difficulty

(slide 19)

drop the requirement, replaced with implementability

compliance

(slide 20)

<sandro> csma: in compliance model, some options must be optional

discussion of levels of compliance with RIF: should be possible to opt out of some features, but not out of all

<sandro> weird loud noise on the phone line.

DaveReynolds: RIF will define a compliance model, which allows for optional features

implementability

(slides 21 and 22)

Resolved to keep both: RIF should use standard support technologies (XML, parser generators) and "RIF should be implementable using well understood implementation techniques" in Phase I

(slide 23)

<sandro> Implementing RIF must not require changes to rule systems -- it must be implementable via translators.

discussion of the nature of RIF implementation

<sandro> (agreement on my proposed wording)

csma: rif implementation amounts to implementation of translators from RIF to existing languages

daveReynolds: this is implied by the nature of interchange - no need to make a requirement.

(slide 24)

Low transfer cost, inexpensive representation - dropped as a requirement

<sandro> this is about Efficient Implementation Possible

<sandro> which is a CSF, not a requirement

<sandro> Harold: but Horn has an exponential search space

<sandro> csma: That's about Rule Engine performance --- I'm talking about translator performance.

sandro, csma: efficient implementation is a critical success factor, not a requirement

Efficient implementation: postponed for a future working draft

RDF compatibility

(slide 25)

RDF compatibility: accepting rdf as data, expressing rdf deduction rules, permit sparql queries.

SPARQL queries - left for Phase 2; RDF as data and RDF deduction rules - Phase 1

<sandro> RDF Deduction Rule -- RDF in the conclusion of a rule

RDF deduction rules - moved to RIFRAF

decided that phasing will be part of RIFRAF classification

<scribe> ScribeNick: MarkusK

Requirement: RIF should support RDF triples as data / support RDF/XML

JosB: RDF data model is closely related to RDF deduction rules

csma: you could support triples without the rules

Discussion: what exactly is "RDF data model"?
... And which parts are Phase 1 or Phase 2?

Harold: The term "data model "is unclear. "RDF semantics" or "RDF graph" would be more explicit.

DaveReynolds: a mapping from RDF to RIF is required. We should specify it.

<sandro> in phase 1

JosB: this is not possible in Phase 1. Since bnodes are not in represented Horn logic.
... the RDF semantics is more complex than just the triples. What do we mean here?

Harold: explicitly mention RDF data model without bnodes
... make bnodes an optional requirement

ChrisW: does everybody agree that RIF should accept ground triples (those without bnodes)?

scribe: even when excluding bnodes, types, properties, XML literals, ... would still be required for RIF

Rephrased requirement: "RIF should cover ground RDF triples as data"

JosB: mapping to RIF might generate an infinite number of ground triples

csma: is this a problem of the RIF? Do we have to care about the exact number?
... we just want to interchange.

JosB: so the RIF should not represent the RDF semantics?

DaveReynolds: the requirement now is rather clear, we only discuss about the possible realisation of the requirement now

csma: cover RDF where feasible in Phase 1, and in Phase 2 otherwise

Added requirement: RIF should cover RDF triples as data in Phase 1 where compatible with Phase 1 semantics

GaryHallmark: what does this mean for the RIF? How much RDF is required in the RIF then?

Sandro: just some parts of it have to be representable in the RIF. This does not imply that RDF syntax or parts of it are actually parts of the RIF.

<sandro> Hassan: If RIF covers N3 then does RIF cover RDF?

<sandro> Sandro: Yes, I guess it does! :-)

Added requirement: RIF should cover RDF for Phase 2.

<scribe> Dropped requirement: Support RDF/XML syntax

Support OWL

(slide 26)

Requirement: Support OWL
... "RIF should accept OWL knowledge bases as data"

JosB: various ways of accepting OWL have been suggested

see http://www.w3.org/2005/rules/wg/wiki/Ways_of_using_OWL_KBs_as_data

csma: "tight integration" there would relate to RIFRAF
... both "tight integration" and "external query processor for OWL" are solutions

JosB: they also refer to slightly different requirements, since the achieved interoperation is different

csma: "tight integration of OWL models and rules" appears to be a Phase 2 requirement

<Harold> "tight integration" is usually called "homogeneous combination"; "external processor" is usually called "heterogeneous (hybrid) combination".

csma: integrating OWL and rules tightly might be an objective of the SemWeb activity, but not a primary objective of RIF

Sandro: let us move this to Phase 2 then

Added requirement: RIF should cover OWL KBs as data where compatible with Phase 1 semantics

<DavidHirtle> http://www.w3.org/2005/rules/wg/wiki/Design_Constraints/Terminology

DavidHirtle: the terminology wiki page gives little hints on what "covering a language in RIF" means

<DavidHirtle> mentions "covering"

Chris: "covering OWL KBs" is not covered by calls to external reasoners

<sandro> csma: It's not a requirement that OWL KB's be conveyable in RIF

Dave Reynolds: but the relationship of RIF and OWL must be clarified in Phase 1

Sandro: most of this discussion could be postponed to Phase 2

<Darko> Can a link for the Terminology page be placed also on the main page (for instance together with Glossary) ?

<sandro> Darko, please go ahead and do it.

<scribe> ACTION: Chris to clarify what to say about the relationship between RIF and OWL in Phase 1

Chris explains the difference between external calls for handling OWL and full coverage

csma: "covering" still allows RIF processors to use external calls for handling OWL

<DavidHirtle> sandro, is the stuff in Terminology sufficiently different to warrant being distinct from the glossary?

Sandro: if a language is covered, then you could not distinguish the parts that originate from the language from other parts of RIF
... it is not clear how to invoke external reasoners then

AxelPolleres: it seems that we now go in the direction of providing a completely new RDF syntax in RIF

Further discussion about RDF compliance ...

<AxelPolleres> Clarification: I think that we should have as a general rationale to stay as close as possible with existing syntaxes and only modify/extend where absolutely NECESSARY in RIF.

Chris: "cover" still is different from "black box"

csma: still some clarification needed

<DavidHirtle> (we're all out to lunch)

Summary of Action Items

[NEW] ACTION: Chris to clarify what to say about the relationship between RIF and OWL in Phase 1
[NEW] ACTION: Paula clarifies which deductive rules exactly what goes into phase 1 and what into phase 2 [recorded in http://www.w3.org/2006/06/09-rif-irc]
[NEW] ACTION: Sandro to make sure the Requirements in Charter Phase 1 are in the Requirements Draft, or discussed in WG. [recorded in http://www.w3.org/2006/06/09-rif-irc]
[NEW] ACTION: Paul to clarify what part of production rules can be usefully translated using phase 1 RIF
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/06/17 20:13:49 $