<csma> item+ Admin

<csma> agendum Admin

<csma> agendum+ Admin

<csma> agendum+ Liaisons

<csma> agendum+ Actions review

<csma> agendum+ Public comments

<csma> agendum+ XML syntax of Import

<csma> agendum+ BLD equality/NAU pb

<csma> agendum+ Implementations

<csma> agendum+ Test cases

<csma> agendum+ AOB (next meeting)

<ChrisW> running late

<ChrisW> be there in a min

<csma> Scribe: Adrian Paschke

<csma> scribenick: AdrianP

<csma> next item

<csma> http://lists.w3.org/Archives/Public/public-rif-wg/2009Dec/att-0010/RIF-Telecon-8-Dec-2009.htm

<csma> PROPOSED: Approve minutes from December 8

RESOLUTION: Approve minutes from December 8

<csma> RESOLVED: approve minutes from December 8

<csma> next item

csma: alignment of OMG PRR to W3C RIF
... PRR might reuse the RIF namespace to define conflict resolution

<Harold> Maybe there is a parallel to entailment regimes: conflict resolution strategies could be located at one point for others to reuse.

<csma> next item

close action-963

<trackbot> ACTION-963 Put BUiltins-String on agenda next time closed

close action-962

<trackbot> ACTION-962 Contact Stella about regenerating XML for BUiltins_string closed

close action-957

<trackbot> ACTION-957 Send cd3 closed

close action-956

<trackbot> ACTION-956 Move hexbinary TC with base64binary closed

close action-954

<trackbot> ACTION-954 Submit implementation report closed

close action-953

<trackbot> ACTION-953 Contact josderoo about implementation report and test case submission for eye closed

close action-950

<trackbot> ACTION-950 Send response cd2 closed

close action-949

<trackbot> ACTION-949 Send response DM3 closed

close action-932

<trackbot> ACTION-932 Send the response to W Laun closed

<csma> next items

<csma> next item

<csma> http://lists.w3.org/Archives/Public/public-rif-comments/2009Nov/0001.html

csma: we need Jos on the call for this

<csma> http://lists.w3.org/Archives/Public/public-rif-comments/2009Dec/0006.html

action csma to update public comment list

<trackbot> Created ACTION-964 - Update public comment list [on Christian de Sainte Marie - due 2010-01-12].

<csma> next item

<Harold> http://lists.w3.org/Archives/Public/public-rif-wg/2009Dec/0011.html

Harold: answer to Sandro's question about active links
... active IRI which needs to be dereferenced
... implied goals are useful, in particular for distributed rule bases
... second part of this mail is about the syntax

Sandro: need to understand the semantic difference between both rif:iri and rif:link
... feels to be too heavy weight to use const

csma: Const was defined for rule

Sandro: import is like a built-in

Harold: the IRI in import needs to be actively dereferenced
... we do not formalize the semantics for dereferencing

Sandro: you don't like a pure IRI?

a pure IRI would violate the syntactic principle of RIF

Harold: if we embedd the IRI directly in the role tag we violate the syntactic design of RIF. So we need a type tag like Const

csma: you would prefer to have Const in profile and location?

Harold: yes, Const of type rif:iri or rif_link

<sandro> PROPOSED: Import's location and profile will be Const of type rif:iri

<csma> http://www.w3.org/2005/rules/wg/meeting/2009-04-16#resolution_7

<sandro> PROPOSED: Import's location and profile will be Const of type rif:iri (this overturns a previous resolution, http://www.w3.org/2005/rules/wg/meeting/2009-04-16#resolution_7 )

also importing RDF and OWL as in SWC uses Const rif:iri

+1

<Harold> +1

<sandro> +1

<mdean> +1

<csma> 0

<ChrisWelty> +1

<sandro> Harold: In the PS, you cannot see the difference. It only shows up in the XML.

<sandro> Gary, do you have a vote?

<Gary> 0

ChrisW: it puts the Const into the domain

Michael: constants and the String URI for importing are different things

<Harold> Outside the context of Import, <Const type="&rif;iri">IRI</Const>

<Harold> and <Const type="&rif;iri">IRI2</Const>

<Harold> are not equal.

<Harold> It is no problem that both could link to the same document within Import.

<ChrisWelty> harold, in BLD consts are not contextual

Harold: what happens in import is outside in the model theory

ChrisW: if you equate two const IRIs they are equal
... model theory defines the semantics of const and the semantics of const in import is different

Harold: that why I propose const of type rif:link

Michael: yes, that was ok

<ChrisWelty> i change my vote to abstain

<Harold> My proposal using <Const type="&rif;link">IRI</Const>

<Harold> avoid these questions.

<sandro> I think rif:link raises about 30 more questions that we're not prepared to answer.

<ChrisWelty> that does not avoid it

michael: original proposal was anyURI

Harold: we already have different types of constants

<Harold> My first email had proposed <Link> elements.

<csma> http://lists.w3.org/Archives/Public/public-rif-wg/2009Nov/0056.html

there are LP language which allow to CONSULT distributed knowledge bases

<sandro> <Import location="...." profile="...">

consult behaves like import

<sandro> <Import location="...." profile="...">

Harold: Document can have an base attribute

<Harold> Yes, this would be fully striped.

<sandro> Portland solution: <Import><location>...</location><profile>...</profile></Import>

Michael: problem of striping

<Harold> We already have a similar XML attribute in <Document xml:base="http://example.com/people#">.

Sandro: if we do not stripe, parses needs to know about this exception
... that is why I lean towards using Const
... the other reason is that we might want to import within a rule

<sandro> sandro: These are fine. The reason I prefer Const type=rif:iri slightly is to avoid the parser having to know about Import.

Harold: that what I mean with implicational goal, called assume

<sandro> Portland solution: <Import><location>...</location><profile>...</profile></Import>

Michael: why not <Import location=".." profile=" .. "/>?

<sandro> (Not really recorded, but Chris and Michael sound fairly opposed to the above PROPOSED.)

<ChrisWelty> does the "Portlant solution" have const inside the location?

csma: does not preserve stripping

Harold: like in Const

Sandro: Const has special treatment, since they are a the leafes of the tree

Harold: would introduce a completely new violation

<sandro> PROPOSED: use <Import location=".." profile=" .. "/>

<Harold> +1

<sandro> -0 mostly procedurally, and because it's using attributes for the first time

<MichaelKifer> +1

<Harold> (the second time)

<csma> 0

<Gary> 0

<mdean> 0

<ChrisWelty> 0 really don't care

<sandro> (by procedually, I mean it's very very late to be making this kind of change.)

<Harold> Document(

<Harold> Base(<http://example.com/people#>)

+0 (for more expressive languages we need further types of imports even allowing variables as arguments for meta reasoning)

<Harold> becomes

<Harold> <Document

<Harold> xml:base="http://example.com/people#"

<sandro> (I don't count xml:base as our first attribute)

<csma> RESOLVED: use <Import location='xs:anyURI' profile='xs:anyURI'/> (this overturns a previous resolution, http://www.w3.org/2005/rules/wg/meeting/2009-04-16#resolution_7 )

action Harold to change syntax in BLD and FLD

<trackbot> Created ACTION-965 - Change syntax in BLD and FLD [on Harold Boley - due 2010-01-12].

action csma to change syntax in PRD

<trackbot> Created ACTION-966 - Change syntax in PRD [on Christian de Sainte Marie - due 2010-01-12].

action josb to change syntax in SWC

<trackbot> Created ACTION-967 - Change syntax in SWC [on Jos de Bruijn - due 2010-01-12].

<Harold> (don't think SWC uses any XML syntax)

<csma> next item

<sandro> http://www.w3.org/TR/rif-bld/#Mapping_of_the_Rule_Language

Sandro: I'm not okay with the previous resolution, looking at the candidate recommendation there is no Const

Harold: χbld(loc1)

Michael: it is not even defined in this table

Harold: in the earlier table it is defined
... http://www.w3.org/TR/rif-bld/#Mapping_of_the_Condition_Language

<Harold> "unicodestring"^^symspace maps to <Const type="symspace">unicodestring</Const>

<sandro> Portland solution: <Import><location>...</location><profile>...</profile></Import>

Didn't we say that the XML syntax is not fully defined and might change?

<Harold> XSD:

<Harold> <xs:element name="location">

<Harold> <xs:complexType>

<Harold> <xs:sequence>

<Harold> <xs:element name="Const" type="ANYURICONST.type"/> <!-- type="&xs;anyURI" -->

<Harold> </xs:sequence>

<Harold> </xs:complexType>

<Harold> </xs:element>

<sandro> Sandro: I can't think of any way to justify changing from subelements to attributes, in a Candidate Recommendation.

Sandro: How to explain this change to the world?

<Harold> Right now there is an inconsistency between the

<Harold> XSDs of BLD and PRD

<sandro> +1 extend tjhe meeting 15 miniutes

<MichaelKifer> +1

<Harold> +1

+1

<mdean> +1

<csma> RESOLVED: extend by 15mn

<Harold> http://lists.w3.org/Archives/Public/public-rif-wg/2009Dec/0013.html

Michael: problem is the how the semantics of named arguments is defined

<MichaelKifer> f(a->b c->b) = f(c->d a->b)

Michael: this kind of implicit equality is there even if we remove equality in the head

csma: but it is already there

<Harold> These equalities are implied by our use of bags (multisets) in the semantics.

<Harold> So, this may be fine.

Michael: if we decide to have it, it will force us to change the semantics of named arguments

Harold: we already use bags which implies equality

<MichaelKifer> f(a->b c->b) <-> f(c->d a->b)

Michael: can change the semantics and introduce such tautologies

ChrisW: isn't it easier to remove named arguments

csma: removing named arguments would be a substantial change

Harold: bag implies equations, but they are built-ins equations

Michael: equality in the head was made at risk because it is hard to implement
... if we allow this implicit equality we have the same problem

Harold: implementation is to build the normal form, you create a lexiographic ordering

Michael: ok

csma: close the discussion about nau and equality

<Harold> Our special axiomatic unconditional equations (which could be oriented for normalization into canonical forms -- e.g. using the lexicographic order of the argument names).

<Harold> No real problem,

<Harold> because we don't explicitly axiomatize them with Equal.

<Harold> We keep it implicit within what the bags of our semantics mean.

<MichaelKifer> f(a->b c->d) = f(c->d a->b)

csma: already written the arguments are an unordered set
... already written in the spec that the arguments are an unordered set

UNDO; RESOLVED: use <Import location='xs:anyURI' profile='xs:anyURI'/> (this overturns a previous resolution, http://www.w3.org/2005/rules/wg/meeting/2009-04-16#resolution_7 )

<csma> PROPOSED: undo previous resolution

<sandro> +1

<ChrisWelty> +1

<Harold> +1

+1

<csma> +1

<mdean> +1

<MichaelKifer> +1

<ChrisWelty> PROPOSED: Exercise every day

<sandro> csma: typical SHORT LIVED new years resolution: 10 minutes.

csma: next meeting Jan, 19th

<csma> Next meeting 19 January

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Adrian Paschke
Found ScribeNick: AdrianP

WARNING: No "Topic:" lines found.

Default Present: Sandro, Harold, Stella_Mitchell, +49.08.aabb, Mike_Dean, csma, AdrianP, ChrisWelty, MichaelKifer, Gary
Present: Sandro Harold Stella_Mitchell +49.08.aabb Mike_Dean csma AdrianP ChrisWelty MichaelKifer Gary
Regrets: LeoraMorgenstern JosDeBruijn HassanAitKaci
Agenda: http://lists.w3.org/Archives/Public/public-rif-wg/2010Jan/0000.html
Got date from IRC log name: 05 Jan 2010
Guessing minutes URL: http://www.w3.org/2010/01/05-rif-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report