See also: IRC log
<scribe> scribenick: igor
Phase 1: clear and precise semantics.
<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
Phase 1. RIF should have a standard way to specify the intended semantics (or style) of the rule set in RIF
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 like author, rule name, is Phase 1.
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
dropped
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.
<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
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.
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
chris: phase 2
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.
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
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
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.
drop the requirement, replaced with implementability
<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
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
<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.
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: 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
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)