See also: IRC log
<csma> Scribe: Adrian Giurca
<csma> scribenick: agiurca
<csma> topic #rif 4 December RIF telecon, agenda: http://lists.w3.org/Archives/Public/public-rif-wg/2007Dec/0001.html
<ChrisW> Scribe: agiurca
yes
<csma> http://lists.w3.org/Archives/Public/public-rif-wg/2007Dec/0001.html
<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2007Nov/att-0084/2007-11-27-rif-minutes-edited.htm
<csma> actually http://lists.w3.org/Archives/Public/public-rif-wg/2007Dec/att-0005/2007-11-27-rif-minutes-revised.htm
ChrisW: Minutes of last telecon, approved
csma: Axel has a formal action (not official) to send a reply to a public comment
AxelPoleres: I did not answer yet to the public question but I will do it immediate
<josb> Axel was not there last time
<Harold> If it's only one week till MichaelK is back, then we might wait.
ChrisW: Jos, can you reply to the Peter email?
JosB: I can answer to some questions but many of them are related to design questions (i.e. Michael and Harold)
ChrisW: Move to next agenda: Liaison
<PaulVincent> Liaison: might be of interest: OMG are holding a vocabulary management meeting next week
csma: Next F2F in Paris
<ChrisW> Feb 21-22 next F2F
ChrisW: We have to vote for Paris/Galway location
JosB: Which thinks will be sponsored by ILOG?
csma: I have to complete with other info (such as dinner etc)
sandro: Do we have special rates for hotels?
csma: I have to check the rates too.
<AxelPolleres> BTW: reply mail to public-rif-comments is sent.
<csma> ACTION: axel to reply to public-rif-comment [recorded in http://www.w3.org/2007/12/04-rif-minutes.html#action01]
<rifbot> Created ACTION-388 - Reply to public-rif-comment [on Axel Polleres - due 2007-12-11].
<ChrisW> ACTION: jdebruij to make a pass on the wiki page for responses to public comments [recorded in http://www.w3.org/2007/12/04-rif-minutes.html#action06]
<rifbot> Created ACTION-389 - Make a pass on the wiki page for responses to public comments [on Jos de Bruijn - due 2007-12-11].
ChrisW: Next item: Issue 42 (rif:text)
<csma> ACTION: christian to finish F2F9 proposal [recorded in http://www.w3.org/2007/12/04-rif-minutes.html#action07]
<rifbot> Created ACTION-390 - Finish F2F9 proposal [on Christian de Sainte Marie - due 2007-12-11].
<ChrisW> ACTION: axel to finish f2f9 proposal [recorded in http://www.w3.org/2007/12/04-rif-minutes.html#action11]
<rifbot> Created ACTION-391 - Finish f2f9 proposal [on Axel Polleres - due 2007-12-11].
<ChrisW> ACTION: sandro to set up wbs for f2f9 on friday [recorded in http://www.w3.org/2007/12/04-rif-minutes.html#action12]
<rifbot> Created ACTION-392 - Set up wbs for f2f9 on friday [on Sandro Hawke - due 2007-12-11].
<josb> issue 42: Conceptually a text constant is a pair of a unicode string and a language tag.
<josb> Currently we handle this by means of a rif:text datatype. By virtue of the current definition of a datatype that means it needs a simple lexical space which is currently described as "string@lang". However, in the XML representation we will use the xml:lang attribute to carry the language code and the string will be conveyed in the element content. So the "string@lang" lexical form is not explicitly part of the XML representation and a RIF processor, working from XML, would not be expected to explicitly materialize the "string@lang" lexical form at any stage. It is unclear whether this is a problem, or a possible confusion that needs to be explained further or a non-issue. We are raising it as an issue to record that we have thought about it and may need to examine it further in the future but it is not something we currently regard as a barrier to at least the next working draft.
No comments of Sandro regarding rif:text issue
<sandro> which is to say -- I'm not really happy with this solution -- just using the mapping table -- but I don't see any serious harm from it, so I wont object.
<ChrisW> PROPOSED: Resolve Issue 42 such that the relationship between the xml syntax treatment of constants and the presentation treatment of constants is specified in the syntax mapping table
sandro: I think the issue should be closed as Chris proposed
<sandro> -0: I wont object
<sandro> (abstain)
<DaveReynolds> (abstain)
<josb> (abstain)
No other objections
<ChrisW> RESOLVED: Resolve Issue 42 such that the relationship between the xml syntax treatment of constants and the presentation treatment of constants is specified in the syntax mapping table
ChrisW What is the issue around builtins?
csma: A discussion about the mechanism to identify builtins
<PaulaP> http://www.w3.org/2005/rules/wg/wiki/List_of_BLD_built-ins
<PaulaP> lists also a couple of issues to be discussed
ChrisWSeems that builtins will be identified by IRI...
<AxelPolleres> I was offline the last few days, but I also feel unease with it!
josb I would object on that. We need syntactic distinction between builtins and other predicates!
AxelPolleres We need distinguish them syntactically.
<sandro> +1 Axel, a builtin should be part of a dialect, syntactically.
<AxelPolleres> ... and a dialect should also define under which binding patterns they are usable.
<PaulaP> +1 for built-ins as part of a dialect
csma I would expect people to react to the emails concerning a specific subject
josb They say (csma) that should be a fixed list of builtins but I'm in favor of an open list
<IgorMozetic> +1 for josb: i.e. having an open ended list of builtins
<AxelPolleres> the list IS extensible by dialect extensibility... why would we want two extensibility mechanisms?!?
<csma> May I suggest that we use two different names: builtin for what is fixed and belongs to a dialect
<csma> and eg external call for what is open and free
csma I'm in favor of an open list of builtins
... The dialect should also have a fixed list of builtins part of it.
<PaulaP> +1 for csma's point
<sandro> +1 csma: fixed list of bultins, open list of external calls
<sandro> +1 Axel: it's important for a receiver to know whether a given function is expected to be built-in or not.
csma A specific dialect has a specific list of builtins which are external calls necessary to be implemented
... but out of that there might be other external calls
MichaelKifer I propose an action to JosB or AxelPolleres to clarify addressing of builtins
<Harold> Where the IRI of a 'builtin' points (to a RIF dialect or to some external library), would show what kind of 'builtin' it is.
<AxelPolleres> just to make clear: I do NOT want 2 different forms of built-ins/external function calls. I was rather suggesting that only the ones defined in the dialect should be allowed. If you need more, extend the dialect.
<Harold> With IRIs as the distinguishing element, we would not need other syntactic means.
Recall the MichaelKifer proposal: an action to clarify addressing of builtins
<AxelPolleres> As long as this is not subject to interchange, all is fine :-)
<sandro> The question is: do app-specific parts of a system need to be part of a new dialect?
<csma> If you do not accept that some elements required for an interchange will be agreed on out of band, you will have very little actual interchanges
<sandro> +1 Axel: app-specific parts should be part of a dialect definition, if you want to interchange them.
<sandro> The question, csma, is whether that agreement is equal to agreeing to some dialect.
ChrisW We should allow people to extends their list of builtins
<sandro> +1 Chris: We all agree that folks should be able to extend the list of builtins, we just disagree about whether to call that new agreement is called a 'dialect'.
csma We need that two parties can extend the fixed list of builtins
<sandro> -1 csma: The label 'dialect' matters because it forbids out of band agreement. [ I don't see that at all. ]
<sandro> Chris: (1) agrrement to have call some-uri
<csma> To Sandro: that's what I have been saying all the time. That's why I think that I disagree with Axel
<sandro> Chris: (2) the list of external calls specified by a dialect are "the builtins"
<sandro> Chris: (3) you should be allowed to extend that list among consenting parties -- BUT we're not agreed at the moment about whether to call that extension a new dialect.
<AxelPolleres> option a) we allow metadata to say "ruleset R is dialect D + builtin (X) which semantics is defined somewhere else" b) we only allow metadata to say "ruleset R is in dialect D' "
<Harold> Since different RIF dialects D1, ..., Dn should be allowed to share a given set of builtins B, D1, ..., Dn should point to B a la D1->B, ..., Dn->B, rather than 'adding' B into D1, ..., Dn as new dialects a la D1+B, ..., Dn+B.
<AxelPolleres> but then we agree on a dialect? right? and whether we decide to writye down the dialect and publish it is our own business.
<sandro> Chris: (4) We're also not agreed about whether we need a formal mechanism about extending the list of builtins.
ChrisW We can close this issue
<josb> issue 40: At the moment the WG has agreed to support "builtins", in particular those defined for supported XS datatypes, however the syntactic and semantic treatment of builtins has not been made clear. One issue is how they will relate to functions in the syntax (e.g. are builtins just logic functions?). Another issue is whether builtins will be sensitive to "order" as they are in query languages and production rules; in these cases, the order is understood to be required to "bind" variables before the builtin is called.
csma: this discussion is just a small part of the Issue 40
<josb> right
<sandro> PROPOSED: The XML syntax for BLD will distinguish between external calls (including builtins) and logic functions
MichaelKifer: We need a concrete proposal from Axel.
<sandro> csma: there was one proposal that the use of URIs be the distinguishing factor, but now we see that wont do.
<csma>:
<op>
<Const type="rif:iri">
http://www.w3.org/2005/xpath-functions/#dateTime"
</Const>
</op>
<AxelPolleres> I take an action to review Michael's two proposals again and suggest something else if needed. My alrernative would be something like
<op>
<ExtFunc type="rif:iri">
http://www.w3.org/2005/xpath-functions/#dateTime
</ExtFunc>
</op>
MichaelKifer: We have to see more proposals
<PaulaP> I think this is about binding patterns
<csma> ACTION: apollere2 to review the discussion about external calls, including Michael's 2 proposals [recorded in http://www.w3.org/2007/12/04-rif-minutes.html#action13]
<rifbot> Created ACTION-393 - Review the discussion about external calls, including Michael\'s 2 proposals [on Axel Polleres - due 2007-12-11].
<Harold> Order in conjunctions: And(?x=3 add(?r ?x ?x)) vs. And(add(?r ?x ?x) ?x=3).
MichaelKifer: Don't mention nothing about errors. They should be left to implementations
<PaulaP> there are also no binding patterns specified in SWRL
<AxelPolleres> paulap, so I can write: ?X ex:gt ?Y <- ?X < ?Y, the question is how this shall be implemented.
<Harold> Let's use "mode" rather than "binding pattern".
<Harold> (otherwise confusion risk between "binding" and "binding pattern").
<Harold> Re Mediawiki: We used advanced features for formulas etc.
<csma> Mike, will you be able to scribe next Tuesday?
<PaulaP> (still, it is a good idea not to discuss 'modes'...we just need to specify the meaning of a built-in, not how it should be implemented)
<AxelPolleres> I need to go, sorry
<Harold> Since we have many other things to change, there would an increased need for version maintenance.