<ChrisW> Scribe: Mike Dean

Admin

<ChrisW> Meeting: RIF Telecon 17 Oct 06

<ChrisW> ScribeNick: mdean

<ChrisW> Hi, Mike

hi chris

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-rif-wg/2006Oct/0056.html

<ChrisW> zakim is all set up mike, with agenda, you can move to the next item with "next agendum"

<ChrisW> ...and we are already on item 1

looks good - i assume sandro will track the details on the action item status

<ChrisW> yes, he or csma

meeting started

<ChrisW> last week's minutes: http://lists.w3.org/Archives/Public/public-rif-wg/2006Oct/att-0011/03-rif-minutes.html

<scribe> Chair: think about whether we should have telecon on oct 31 right before F2F 4

RESOLUTION: minutes approved

<DaveReynolds> http://lists.w3.org/Archives/Public/public-rif-wg/2006Oct/att-0028/10-rif-minutes.html

<ChrisW> csma are you coming to the telecon

corrected URL posted

no objections to approving 10 October minutes

no amendments to agenda

F2F

peter not on telecon

mdean: ISWC2006 bus schedule now available at http://iswc2006.semanticweb.org/bus_sch.doc
... mostly for main conference - doesn't necessarily help for f2f 4

sandro: room available for f2f5 at MIT - week of January 25

<scribe> Chair: only proposal for F2F5

<scribe> Chair: nobody has volunteered to host F2F6 at WWW2006 in Banff

<AxelPolleres> We have made the proposal to colocate with ESWC in Innsbruck, yes.

<scribe> Chair: DERI proposal to host F2F6 in conjunction with ESWC in Innsbruck

<josb> eswc2007 is june 3-7, 2007

<scribe> Chair: decide on F2F5 by November 4

<scribe> Chair: don't need to decide on F2F6 this far in advance

Liaison

<johnhall> Nothing for SBVR

<cgi-irc> PRR: no news

<scribe> Chair: action review

ACTION-119 and ACTION-87 done

Christian action continued

<Harold> http://www.jdrew.org/oojdrew/demo_new.html

Harold: ACTION-140 done - sent email about OO jDREW 0.93.

ACTION-141 open - got permission to release, translating make to ant, should post this week

ACTION-142 continued

Christian: perhaps work on simplified version that doesn't require weaving?

Hassan: interesting, but not most important given limited availability

<Hassan> hello?

Technical Design

<scribe> Chair: lots of discussion on email list regarding syntax of core proposal

<ChrisW> http://www.w3.org/2005/rules/wg/wiki/CORE

<scribe> Chair: can't navigate from one Wiki page to next page

ACTION (Harold): add next/previous links

<scribe> Chair: condition vs. core language

<scribe> Chair: try out core (Horn) language, not just condition language

Harold: entire table of contents is core

<scribe> Chair: laid out like core is an extension of condition - will provide more concrete update proposal

ACTION (ChrisW): provide more concrete update proposal for core and condition layout

FrankMcCabe: for example 4, important that we require explicit quantification of variables (for all or exists)

csma: explicit quantification of free variables in condition

<Francois> +1 with explicit scopes for variables.

Harold: condition language has existential quantifiers - universals not explicit

<scribe> Chair: language ultimately needs to be extended - should allow quantification at rule level, with possible syntactic restrictions

MichaelKifer: tasked to provide small minimal language
... agree that eventually has to be extended with explicit quantification

FrankMcCabe: explicit quantification should be required

<scribe> Chair: expect that software will generate RIF - not losing anything if all translators are explicit about quantification

MichaelKifer: human readable syntax may be used directly

csma: strongly disagree

<sandro> +1 MKifer it's nice to avoid gratuitious verbosity

MichaelKifer: don't deliberately cripple the language

<Hassan> I agree with Chris - an implicit default quantification of unquantified variables can always be derived from a sugared syntax

MichaelKifer: lots of logic languages don't have explicit quantifiers

<scribe> Chair: make sense to makes quantification explicit

Harold: simple connection with human readable syntax could be lost - might also need explicit quantifier syntax - but agree it should be explicit for interchange

<GerdWagner> +q

<scribe> Chair: don't make design decisions based on human readability

<scribe> Chair: design goal to enable translation software

<FrankMcCabe> +q

csma: third part of rule ...

Hassan: discussion worries me - similar to ACTION-87
... are we creating ASTs for rule language?
... what people will use is XML vocabulary for RIF
... RIF Condition Language (RCL) won't be target of translators

Gerd: what about going beyond Horn

<scribe> Chair: explicit quantification, with syntactic restrictions for Horn

<AxelPolleres> We can add a similar formulation as for when we allow to shortcut facts.

FrankMcCabe: relation symbol is unnecessarily simplistic - some languages support structures, variables, or objects
... even RDF supports this
... rel should be expression

MichaelKifer: minimal language - could have defined something like HiLog or CL with structured terms and objects within predicates
... nucleus language that can be extended

FrankMcCabe: not extensible

MichaelKifer: oversight - proposal separates relational functional symbols and constants - new proposal just uses constant (including relation symbol)

FrankMcCabe: does first XML element identify relation?

MichaelKifer: yes

ACTION (MichaelKifer): send updated proposal to list

FrankMcCabe: first XML child seems clumsy, but should work

Harold: constants could handle more advanced cases

sandro: apparent consensus that conceptually, variables should be quantified, but XML may allow abbreviations

<Zakim> sandro, you wanted to ask if the question here is whether quantifiers may be omitted for brevity, or if there's some other question.....

MichaelKifer: not opposed to making it explicit in serialization
... people will likely use RIF as KR language
... fine with mandatory XML quantifiers

<sandro> MichaelKifer: I am fine with manditory quantifiers in the XML serialization, but I want them to be omitable in the human-readable serialization.

Francois: function symbols demonstrate need for different styles of dialects - perhaps specify with default options

<Hassan> +1 with Francois

Axel: is PC data sufficient or should we allow URIs for relation and constant identifiers

<cgi-irc> -1 on implicit design aspects of RIF supporting role as new rule language [which is not a requirement / CSF, AFAIK]

<AxelPolleres> <rcl:rel rdf:resource="http://ex.org/myRel"/>

Harold: like webizing of relation names - likely to use attribute
... in bipartitioned part of proposal

<scribe> Chair: why partitioned part? what's being sorted?

Harold: XML syntax in "Bipartitioned Constants" document distinguishes between Ind and Data elements; ... also accommodates webizing via optional attributes pointing to individual and datatypes definitions

<FrankMcCabe> instead of <rel>foo</rel>

<FrankMcCabe> we should have

<FrankMcCabe> <rel name="foo"/>

<FrankMcCabe> because that plays better with namespaces

<Hassan> But Frank - does it really matter at this spoint?

<scribe> Chair: language based sorts - perhaps different use of term

<DaveReynolds> It matters when we need to actually exchange the AST

<FrankMcCabe> yes. this was one of the biggest issues with parsing RDF properly

<Hassan> I share ChrisW's bafflement regarding the importance of issues regarding URI/IRI vs. symbols - whatever the vocabulary is will do!

<AxelPolleres> What would hamper us from just reusing the rdf:resource and rdf:datatype as in RDF and wouldn't this solve the problem?

FrankMcCabe: better to use attributes than PCDATA
... also allows entities and namespaces

<AxelPolleres> ... in the XML syntax.

FrankMcCabe: nothing to do with sorts

<sandro> MichaelKifer: URIs are just another primitive datatype

MichaelKifer: a URI is yet another datatype - under old proposal, names of relations were not in the domain of constants - now handled as primitive datatypes

<FrankMcCabe> this is *NOT* a type issue but a namespace issue!

<DaveReynolds> +1 to Frank

MichaelKifer: will explain in updated proposal

<scribe> Chair: postpone further discussion until we see proposal

<sandro> rofl

<Hassan> +1 Gerd!

Gerd: perhaps more appropriate to focus now on abstract syntax

<scribe> Chair: guided discussion to XML syntax

Axel: will send email to Michael and Harold

sandro: another half of question on URIs
... URI as xsd:datatype (string with restricted syntax)
... not as important as use of URI naming in RDF and OWL

MichaelKifer: URI datatypes won't help with naming - new proposal will eliminate distinction between relation functions and constants
... can later add URI sort to identify relations, etc.

<Zakim> sandro, you wanted to say that URIs have two different roles here -- as data values and as names

<scribe> Chair: any other points about syntax?

<Francois> bye

Gerd: email discussion re which kind of typing support to include in language - or should this be postponed?

MichaelKifer: new proposal talks about primitive types, not complex types that can be constructed - a layer on top of primitive types

<scribe> Chair: required to support XML datatypes

MichaelKifer: adding more complex datatypes is a can of worms and must be looked at very carefully

<scribe> Chair: OWL explicitly identified XML datatypes supported by language - this is a precedent

MichaelKifer: likely proposals for even more complex data types - e.g. from Gerd and Frank

<FrankMcCabe> not all scalar datatypes are scalar!

MichaelKifer: suggest delaying anything but primitive datatypes to phase 2

Harold: Data element can carry 'type' attribute for XML Schema Part 2 Datatypes,
... as described in "Bipartitioned Constants" document

Hassan: be careful not to reinvent the wheel
... inventory what we need and then look at other W3C Recommendations and reuse if possible
... annoyance at overly detailed trivialities

<sandro> note the charter on datatypes: http://www.w3.org/2005/rules/wg/charter#datatype0

<AxelPolleres> I think we should wait for Michael's and Harold's proposal, and then see, whether it is sufficiently reusing....

Hassan: identify datatypes that we need for our purpose

<AxelPolleres> and then discuss this further.

<GerdWagner> +1 Hassan

<PaulaP> +1 to Hassan's point

Gerd: without support for basic atom types we cannot support interchange between iLog full language and SWRL
... need to type predicates and atoms (atomic formulae)
... can support within Horn fragment - must be in core
... support translation between OO rule languages and SWRL

Harold: XML attributes might do the job

MichaelKifer: working in same vein as Gerd

<scribe> Chair: core language will not be sufficient for translating all rule languages - need extensions for complete translations

<csma> but some fractions of useful RF into fractions of other useful RL; and maybe implement some useful rule interchange

UNKNOWN_SPEAKER: core should include common features of many languages
... XML syntax focus for experimentation (also WG requirement)

<Zakim> sandro, you wanted to talk about charter on datatypes

sandro: some people work better with abstract syntax, some with XML - need both
... phase 1 calls out specific XML datatypes we need to support

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

FrankMcCabe: risk is missing features that make extensions harder
... have to think about this now even if we don't do anything now

Hassan: not denigrating XML - think it's important - we're using "syntax" carelessly

<sandro> That's a fascinating question, ChrisW -- should there be some kind of requirement about how much extensions change or don't change the language?

Hassan: XML desirable formalism to represent ASTs

<ChrisW> hassan

<ChrisW> wrap up

Harold: Frank's concern about missing higher-order-like features later when having an elementary Rel in the first child position of Atoms now can be addressed by using a first child content model with a choice of Rel | Var | Expr, where Expr would evaluate to a relation. However, it is preferable to use Con | Var | Expr, as in Michael's new proposal, since no need then to distinguish Vars bound to an Ind or a Data from Vars bound to a Rel or a Fun.

RIF-RAF

ACTION-148 continued

ACTION-149 continued

<PaulaP> DONE

ACTION-150 completed

<scribe> Chair: RIFRAF task force 2 weeks ago to develop OWL ontology

<LeoraMorgenstern> It was last week, not 2 weeks ago!

Alex: more discussions with JBOSS
... difficulties in following current RIFRAF
... JBOSS includes accumulate construct
... translation to rules would be inefficient and perhaps incorrect
... need linkage between object representations and RIF

Leora: 6 members on task force (Sandro, Axel, Hassan, Allen, Leora, Frank)
... telecon last week

Leora: construct OWL ontology of RIFRAF discriminators
... divided discriminators among members
... no timeframe yet (subject of discussion)
... perhaps use Protege
... will also provide commentary on current discriminator set - clarification

<AxelPolleres> http://lists.w3.org/Archives/Public/public-rif-wg/2006Oct/0036

Leora: integration of subontologies will be next task

<Allen> no

<Hassan> NO!

<scribe> Chair: start by F2F4?

<Hassan> move on

UCR

John Hall posted update today

ACTION-131 continued, but nearly finished

Allen complete

<csma> continued

ACTION-145 complete, email sent

ACTION-146 complete

ACTION-147 continued

AOB

<PaulaP> bye

<scribe> Chair: adjourned

<Hassan> #quit

<GerdWagner> quit

<GerdWagner> help