See also: IRC log
<ChrisW> Scribe: Mike Dean
<ChrisW> Meeting: RIF Telecon 17 Oct 06
<ChrisW> ScribeNick: mdean
<ChrisW> Hi, Mike
<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
<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
<ChrisW> csma are you coming to the telecon
corrected URL posted
no objections to approving 10 October minutes
no amendments to agenda
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
<johnhall> Nothing for SBVR
<cgi-irc> PRR: no news
<scribe> Chair: action review
ACTION-119 and ACTION-87 done
Christian action continued
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
Christian: perhaps work on simplified version that doesn't require weaving?
Hassan: interesting, but not most important given limited availability
<scribe> Chair: lots of discussion on email list regarding syntax of core proposal
<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
<scribe> Chair: don't make design decisions based on human readability
<scribe> Chair: design goal to enable translation software
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?
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
<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
... 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?
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> 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.
<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
... 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
... divided discriminators among members
... no timeframe yet (subject of discussion)
... perhaps use Protege
... will also provide commentary on current discriminator set - clarification
Leora: integration of subontologies will be next task
<scribe> Chair: start by F2F4?
<Hassan> move on
John Hall posted update today
ACTION-131 continued, but nearly finished
ACTION-145 complete, email sent
<scribe> Chair: adjourned