RIF telecon 25 November 2008 -- 25 Nov 2008

<csma> Scribe: Adrian Paschke

<csma> agendum+ admin

<csma> agendum+ liaisons

<csma> agendum+ public comments

<csma> agendum+ review actions

<csma> agendum+ TF updates

<csma> agendum+ UCR

<csma> agendum+ publication plan

<csma> agendum+ DTB

<csma> agendum+ AOB (pick scribe!)

http://lists.w3.org/Archives/Public/public-rif-wg/2008Nov/att-0125/2008-11-18-rif-minutes.htm

PROPOSED: accept minutes of last weeks telecon

RESOLUTION: accept minutes of last weeks telecon

admin

liaisons

<josb> http://lists.w3.org/Archives/Public/public-owl-wg/2008Nov/0122.html

<josb> http://lists.w3.org/Archives/Public/public-owl-wg/2008Nov/0110.html

<josb> Discussion with OWL working group
ID, IDREF and entity was excluded in OWL, XML literal was included
Jos: value space of XML literal as defined in RDF is not adequate
Jos: RDF text is not an XML datatype

<DaveReynolds> Jena does cannonicalization I believe and is supposed to implement XMLLiteral correctly.

<josb> http://www.w3.org/TR/rdf-concepts/#section-XMLLiteral

<josb> http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

<DaveReynolds> http://www.w3.org/2001/sw/RDFCore/errata#rdf-concepts says Ivan is the editor of the errata document.

<scribe> ACTION: sandro to figure process for RDF errata (re: fixing rdf:xmlliteral) [recorded in http://www.w3.org/2008/11/25-rif-minutes.html#action01]

<trackbot> Created ACTION-664 - Figure process for RDF errata (re: fixing rdf:xmlliteral) [on Sandro Hawke - due 2008-12-02].

public comments

<Chris> Repsonse to OKeef ready to be send out Chris: Gary and Christian took an action to respond to Kowalski Chris: Gary took over the action from Christian to answer to Bob Kowalski

<csma> I did not progress on the RAK comment. Give me 'till Friday EOB.

review actions

<Chris> see http://www.w3.org/2005/rules/wg/track/actions/open
http://www.w3.org/2005/rules/wg/track/actions/open

<csma> I can do the closing etc

<csma> yes

<csma> done

<josb> http://www.w3.org/2005/rules/wiki/IRI_from_IRI

<AxelPolleres> continued

<csma> 592 is continued

<Hassan> ctd ...

<csma> that's a PRD TF action

TF updates

<Chris< Presentation syntax

<Chris< no TF meeting on last Friday

<Dave< Substantive issues of Core

<Dave< where external function calls are allowed?

<Dave< we discussed several options how to restrict that calls

<Dave< restrict external functions calls in equations

<Dave< safte criteria was fixed to be more clear

<Dave< membership / subclass is still open

<Dave< put editors note for these open issues

<CSMA< need for rewriting in PRD spotted by Gary

<CSMA< we must isolate everything that is not possible to have in a purle forward-chaining implementation in Core

<Michael< it is not just a problem of forward chaining - the issue is if the system can do constraint solving or not

<Dave< within Core we have defined the safety conformat

<Gary> what do we do with a rule: P(?x - ?y) :- P(?x + ?y)

<DaveReynolds> Gary - that rule would be unsafe by the current criteria.

<Michael< it is a notion of conformance which some systems can choose if they e.g. use PRD

<chris< PRD

<csma< discussion about subcalls and membership

<csma< we came to a consensus and write an editors note

<csma< today we will discuss "New"

UCR

<chris< UCR

<adrian< two new requirements proposed one for RIF internationalized text

<adrian< othere requirement, state explicitly that RIF must support intra-dialect interchange and should support inter-dialect interchange

*PROPOSED:* Include in UCR new requirement "Internationalized text: RIF must support internationalized text - that is, text that additionally conveys information in terms of a language tag."

PROPOSED: Include in UCR new requirement "Internationalized text: RIF must support internationalized text - that is, text that additionally conveys information in terms of a language tag."

other requirements: RIF must support inter-dialect interchange

other requirements: RIF must support intra-dialect interchange

*PROPOSED:* Include in UCR new requirement "Internationalized text: RIF must support internationalized text - that is, text that additionally conveys information in terms of a language tag."

PROPOSED: Include in UCR new requirement "Internationalized text: RIF must support internationalized text" - that is, text that additionally conveys information in terms of a language tag.

RESOLUTION: Include in UCR new requirement "Internationalized text: RIF must support internationalized text" - that is, text that additionally conveys information in terms of a language tag.

<chris< first requirement resolved; do we need the second requirement? Is it clearly stated?

<Sandro< two languages can interoperate if the document they are interchanging is in the intersection

<sandro< but how to phrase it as a requirement

<StellaMitchell> the conclusion of UCR says:

<StellaMitchell> Developing criteria for understanding and managing RIF inter-dialect translations is not within the current phase of RIF working group activity.

<StellaMitchell> the CSF that was removed said: Encouragement of Interoperability: RIF will encourage interoperability, e.g., overlap between dialects and distinguished dialects with maximum overlap.

<chris< originally we had the critical success factors

<chris< adrian, can you send an email to the list about text proposal for the second requirement

<sandro< suggestion to add a place holder for the hidden examples

publication plan

<csma< PRD

<csma< we need the reviews for PRD

<csma< once we have resolved this we are done with respect to publication

<chris< FLD is under a lot of change, so it will not be released now

<chris< DTB is almost ready to go, one action is open

<chris< Core was frozen, it is not 1st WD

<chris< PRD is frozen and needs to be reviewed, some small changes pending

<chirs< Test needs to be reviewed and can then be voted as 1WD

<Chris< UCR ready to go, some editorial changes can be done

<Chris< BLD is done

<Sandro< resolve publish on Tuesday next week

<Harold< Core should be on the W3C RIF menu on the main page

<Chris< Test should be there, too

<Jos< send some comments to Chris review about RIF SWC - are they ok

<Chris< don't have a major issue with it. Will look at it

<Sandro< Look at formatting problem of Core

<sandro> MediaWiki:Sidebar

<scribe> ACTION: sandro to look at CORE formatting problem [recorded in http://www.w3.org/2008/11/25-rif-minutes.html#action02]

<trackbot> Created ACTION-665 - Look at CORE formatting problem [on Sandro Hawke - due 2008-12-02].

DTB

<Chris> Proposed resolution for built-in

<Axel> remove equality and inequality from editors note

PROPOSED: * Add equal and not-equal builtins for string in DTB.
... Add equal and not-equal builtins for string in DTB.

RESOLUTION: Add equal and not-equal builtins for string in DTB.

<josb> 0

Jos abstains

<AxelPolleres> "Editor's Note: The need of separate equality, inequality, less-than, greater-than, less-than-or-equal, greater-than-or-equal predicates for strings is still under discussion, cf. ISSUE-67."

<AxelPolleres> Editor's Note: The need of separate less-than, greater-than, less-than-or-equal, greater-than-or-equal predicates for strings is still under discussion, cf. ISSUE-67.

ISSUE-79: Negative guards

<Chris> issue negative guard in DTB

http://www.w3.org/2005/rules/wiki/Disjunctive_Information_from_Negative_Guards_1

<trackbot> ISSUE-79 Negative guards in DTB - is this another dialect? notes added

<Chris> discussed it in the last F2F

<Chris> sneaking negation into the language with negative guards

<Chris> BLD with only positive guards and then an extension of BLD with negative guards

<AxelPolleres> As I understand, dropping neg guards is a problem for OWL-RL

<AxelPolleres> Dave?

<CHris> OWL RL uses negative guards

<Dave> we need it for implementing OWL RL in RIF, e.g. negative guards include consistency checks

<josb> we need them for embedding RIF-OWL DLP combinations (sec 8.2.3.2 of SWC) as well

<AxelPolleres> I likely wouldn't implement full equality... without, it is probably not an issue.

<DaveReynolds> I have a preference for keeping them to allow the OWL/RLtranslation to be expressed within Core.

<AxelPolleres> I don't see how this could affect core at the moment.

<josb> I can live with either option

<Chris> proposal would be to make them (negative guards) and extra dialect

<csma> keeping them means that someone can write unsatisfiable rules

<Chris> Jos has a test case

<csma> you cannot restrict an interchange format to only satisfiable rules

<csma> the authors need to be careful.

<chris> question is if it hinders implementation if we have negative guards and datatype inequality

<chris> making it an dialect is not the same as dropping it

<dave> in the case of Core we don't have equality in the head

<dave> can we safely include negative guards in Core?

<jos> I suspect that there are still issues with negative guards in Core

ISSUE-80 [12] (Shoudl we extend DTB to include more general builtins)

<Harold> We could have parameterized dialect schemas, including a "DTB schema" with DTB(NG) being one instantiation (NG = Negative Guard).

<Harold> We already have the beginnings of this with the conformance clauses.

<sandro> Wouldn't the parameterized versions replace the fixed ones?

<josb> I think the negative version is really asking for trouble

<josb> I think it's better to use a dialect with negation and use that negation

<AxelPolleres> +1 dialect with negation seems to be missing desparately, it could safe all these negative builtins

<AxelPolleres> pred:hasDatatype

<AxelPolleres> hasNotDatatype( ?X ?Y ) has no intended domain

<AxelPolleres> but neither has isNotInteger( ?X )

<AxelPolleres> for safe Externals, it hasNotDatatype doesn't seem to be less or more problematic than the existing ones.

<Harold> Maybe hasNotDatatype should be replaced with a RELATIVE complement, wrt a higher datatype in the type lattice.

<AxelPolleres> Harold, don't understand what you're after.

<StellaMitchell> pathalogical

<scribe> ACTION: jos to come up with problematic case for general type pred [recorded in http://www.w3.org/2008/11/25-rif-minutes.html#action03]

<trackbot> Sorry, amibiguous username (more than one match) - jos

<trackbot> Try using a different identifier, such as family name or username (eg. jdebruij2, jderoo)

ISSUE-67 [10] (need string predicates string-less-than, etc.)

<Gary> mild pref for string-less-than, for symmetry with numeric and date

<Michael_Kifer> 0

<AxelPolleres> "<" ">" "!=" ...

<AxelPolleres> "=" is still possibly troublesome for such a surface syntax?

<sandro> paschke@inf.fu-berlin.de

- DRAFT -

RIF telecon 25 November 2008

25 Nov 2008

Attendees

Contents