RIF Telecon 10-Mar-09 -- 10 Mar 2009

<ChrisW> F2F13

<ChrisW> hi Harold, you ready to scribe?

Admin

Yes.

<ChrisW> Scribe: Harold

<ChrisW> scribenick: Harold

<AxelPolleres> http://www.w3.org/2001/01/cgi-irc does that one work for her?

<csma> next item

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

Liaison:

Chris: Please read the above email until next week.

Sandro: OWL leaning toward disjointness.

<josb> yippie!

Jos: Only l reply to one OWL2-RL comment:
... Semantics of OWL 2 RL.

<ChrisW> ACTION: csma to put OWL datatypes on upcoming telecon [recorded in http://www.w3.org/2009/03/10-rif-minutes.html#action01]

<trackbot> Created ACTION-712 - Put OWL datatypes on upcoming telecon [on Christian de Sainte Marie - due 2009-03-17].

Sandro: OWL just need to define identity when introducing new datatype.

Jos: Also RIF could introduce certain datatypes (eg rational) without introducing (all kinds of ) builtins on them.

Axel: How about the OWL implementers? Will they actually implement all OWL datatypes?

Sandro: Yes.

Axel: When there is no lexical space?

<AxelPolleres> I think you can write down some reals as literals in OWL but not all... or no?

Jos: Thats why datatype 'real' is the easiest to implement.

<josb> real does not have a lexical space

<DaveReynolds> Yes - its the difference between a new implementation which can easily add one more datatype like Rational v.s. our requirement of implementation-by-translation

Christian: Even if easy to define datatype in RIF, it may be hard to define mappings.

<ChrisW> i imagine something like a predefined conformance level for the extended datatypes, like "RIF+SW"

<csma> http://www.w3.org/2005/rules/wg/track/issues/81

<ChrisW> that's the issue

Axel: SPARQL-RIF liaison person.

<csma> next item

<josb> the 13th F2F? Will that be the unlucky F2F?

<ChrisW> can we stay at a frat house?

<ChrisW> sure

<csma> next item

<ChrisW> ACTION: chrisw to ask JeffP if he will complete his action [recorded in http://www.w3.org/2009/03/10-rif-minutes.html#action02]

<trackbot> Sorry, couldn't find user - chrisw

<ChrisW> ACTION: chris to ask JeffP if he will complete his action [recorded in http://www.w3.org/2009/03/10-rif-minutes.html#action03]

<trackbot> Created ACTION-713 - Ask JeffP if he will complete his action [on Christopher Welty - due 2009-03-17].

Jos: Since discussing remaining bunch of test cases takes too much time in general telecons, we could have a special telecon series for that.

Leora: There's already a kind of Task Force with telecons.

<AdrianP> yes, similar the Core task force can approve Core test cases

Sandro: Approving?

<ChrisW> i think jos is proposing rather an auxiliary telecon, not a task force

<ChrisW> focused just on approving

<ChrisW> how much smaller can we get?

Sandro: Maybe even email approvals.

Jos: People seriously look at them only once they appear on an agenda.

<csma> next item

Sandro: Implementers will need them.

Safeness and termination

<csma> PROPOSED: The issue of finiteness will be At Risk through CR, as we get implementor feedback. We need to know who wants / doesn't want this limitation in Core. (Safeness as defined by Jos not being in question.)

Jos: Axel's stronger safeness condition (prohibit recursion thru externals) could be added to document.

Dave: finite grounding.

<josb> http://lists.w3.org/Archives/Public/public-rif-wg/2009Feb/0067.html

<josb> (email Axel about safeness)

Axel: Two flavors of safeness are implemented.
... Guarding predicate
... Range-restrictedness

Dave: Only having to prove conformance for finite rulesets.

<josb> what is a finite ruleset?

Christian: If you only have to prove for finite rulesets, then you dont say what you'll do with non-finite ones.

Axel: Giving errors for non-finite ones would be an option.

Dave: Forward engines can have a termination criterion, eg counting a variable upward recursively up to a limit.
... that should not be excluded.

Christian: Try to satisfy both criteria.

Dave: Was original split notion of conformance.

<josb> or is it meant that there exists a finite grounding that has the same entailments?

Sandro: Doesnt this cause a bifurcation?
... you wont know if your document is consumed?

Christian: Maybe strong safeness could be made "at risk".

<AxelPolleres> jos, it is "Eiter-Schindlauer-safe" rather than "Axel-safe", I'd say... (although I simplified their notion already)

<josb> Axel-safe sounds better :)

Sandro: Deeply opposed to handle under conformance.

Axel: Right, better strict safeness.

Christian: It's already under conformance.
... intrinsically conformance.

Sandro: Making it optional, is a problem.

<csma> PROPOSED: Axel-safeness will be At Risk through CR, as we get implementor feedback. We need to know who wants / doesn't want this limitation in Core. (Safeness as defined by Jos not being in question.)

<AxelPolleres> it looks like we are stuck with a discussion about BLD-Core-theRealCore on that issue. Meta-comment: do we simpy need something more in between core (which is maybe over-cautious) and BLD?

Dave: How does this connect with what a process should do?

Sandro: Dave's point is similar to being allowed to using some extra datatypes.

Dave: Right.

Sandro: "User switch" seems fine then.

<sandro> "is outside Core"

Sandro: "outside Core" seems clearer phrasing.

Jos: Dave's earlier proposal, with Axel happy: there exists a finite grounding of ruleset with same entailments.

Axel: But not decidable.

Jos: Fwd engine could do it in practical cases.

<josb> Jos: Axel is apparently not happy with it, so nevermind

Christian: If non-Axel-safe document is rejected, is not required to be that enough?

Dave: Yes.
... current "at risk" clause in Core is fine.

<AxelPolleres> the problem is if the answer to "I am not required to implement this" is undecidable, we get in trouble, that is why I wanted to restrict this to something syntactically checkable

Sandro: User setting a flag "outside of core" fine with Dave?

Dave: Yes.

Sandro: In this case, fine.
... what happens if everyone turned that on?

<csma> PROPOSED: Core will be Axel-safe, but consumer will be allowed to accepted non-Axel-safe but otherwise valid Core documents, provided they notify the user in some way.

<AxelPolleres> -1, objecting againt the notion of "Axel-safe" in a formal WG resolution.

Sandro: Decide at end of CR how it works out.

<csma> PROPOSED: Core will be Eiter-Schindlauer-safe, but consumer will be allowed to accepted non-Axel-safe but otherwise valid Core documents, provided they notify the user in some way.

<josb> but this will be at risk, right?

<ChrisW> accdept and produce?

<AxelPolleres> +1 that's fine for me (also with "at risk")

<csma> PROPOSED: Core will be Eiter-Schindlauer-safe, but consumer will be allowed to accepted non-PROPOSED: Core will be Eiter-Schindlauer-safe, but consumer will be allowed to accepted non-Eiter-Schindlauer-safe but otherwise valid Core documents, provided they notify the user in some way.

<csma> PROPOSED: Core will be Eiter-Schindlauer-safe, but consumer will be allowed to accepted non-Eiter-Schindlauer-safe but otherwise valid Core documents, provided they notify the user in some way.

Sandro: Core would be Eiter-Schindlauer-safe, but extended-Core docs could be flag-allowed.

<cke> Hi all, I quit you to join another meeting. Regards.

<josb> consumers cannot produce :)

Chris: This requires implementations to do the check.

<ChrisW> consumers and producers are not disjoint, jos :)

Axel: Very much stronger safeness notion would be easier to check.
... Datalog below that.
... Eiter-Schindlauer-safe is harder to check and just extends the Datalog notion.

<josb> I thought we just had Core and BLD?

<sandro> PROPOSED: For now, "at risk", we'll say: Core consumers must do the Eiter-Schindlauer-safeness check. They must handle documents which pass the test; they must reject documents which fail the test as "outside core", unless the users specify it is okay to handle documents outside core. Producers of Core documents must not produce documents which fail this test.

<josb> did not know we had anything in between

Harold: Range-restrictedness

<AxelPolleres> I need the strong safety notion just for the sake of the "right to reject", so I am fine if the test is simple.

<josb> Axel, I think you are the only who is concerned about how easy it is to implement the test

<ChrisW> mini-core?

Sandro: Sounds like two languages.

<AxelPolleres> +1 to Core and SafeCore

Harold: But still it's only one core language, with different levels.

<josb> So Core has no safeness condition at all?

<DaveReynolds> I would prefer Sandro's proposal in IRC to having two dialects.

Harold: Maybe call these levels "language-levels".

<AxelPolleres> That doesn't need a separate document. Core doc could stil ldefine both core and safe core.

Harold: but dont introduce a new dialect.

Dave: We want a minimal # of dialects.

Sandro: One or the other 'dialects' would be at risk.

<josb> let's consider csma's proposed resolution again?

<csma> PROPOSED: Care will defined two options: Core restricted to safe documents (as defined in the Core document [http://www.w3.org/2005/rules/wiki/Core#Safeness]) and Core restricted to Eiter-Schinlauer-safe. Both will be at risk to CR, and only one of them will be REC.

<sandro> (PROPOSED: For now, one'll specify two dialects Core-A and Core-B. We'll pick one at the end of CR. )

Harold: Normally, decisions about an aspect of a spec are not 'propagated upward', leading to a 'copy' of the entire spec, putting that up for votes.

<AxelPolleres> what about calling them Forward-safe backward-safe?

Chris: Agreed to have only one Core.

<josb> Axel: no

Chris: One paragraph "At Risk".

<AxelPolleres> josb: :-)

<josb> safeness is always concerned with forward-chaining

<sandro> Chris: at risk will be one paragraph, stating the Eiter-Schinlauer safeness criterion.

Chris: If you remove that paragraph, you have a different language.

Sandro: Thats clear.

<AxelPolleres> then why not only one notion of dafety at all which does guarantee finite Herbrand models are enough (= safeness)?

<josb> :D

Sandro: Eiter-Schindlauer-safeness in Core, but mark it "at risk".

<josb> Axel, Axel-safeness guarantees finite minimal models

Sandro: We dont need a special case where you could go outside of Core thru a conformance clause.

<csma> PROPOSED: Core will be Eiter-Schindlauer-safe, but that restriction will be at risk (not putting in question simple safeness as defined in http://www.w3.org/2005/rules/wiki/Core#Safeness)

<ChrisW> should we open an issue on this that we will resolve after implementor feedback?

<sandro> (PROPOSED: We'll handle outside-of-core like we handled outside-of-BLD --- let users set a flag if they want to allow it.)

<ChrisW> (sections of documents have a tendency to remain)

<josb> can we vote?

<AxelPolleres> josb: I would be fine with the stricter notion only allowing finite minimal *Herbrand* models... as a fallback, which I still believe to have been the core idea behind safeness a la ullman

Chris: Even if we get not feedback externally, we need to come back to it, hence make it an issue.

<sandro> +1

<DaveReynolds> +0.1

<AxelPolleres> +1

<ChrisW> 0

<josb> +!

<AdrianP> 0

<josb> +1

<MichaelKifer> 0

<ChrisW> that's leet for +1

<josb> you mean, l33t?

<csma> RESOLVED: Core will be Eiter-Schindlauer-safe, but that restriction will be at risk (not putting in question simple safeness as defined in http://www.w3.org/2005/rules/wiki/Core#Safeness)

<ChrisW> y1

<ChrisW> 1337

<ChrisW> ACTION: chris to open issue on safeness [recorded in http://www.w3.org/2009/03/10-rif-minutes.html#action04]

<trackbot> Created ACTION-714 - Open issue on safeness [on Christopher Welty - due 2009-03-17].

<csma> mext

<csma> next item

<csma> close item 7

<csma> next item

Christian: Only see what are the remaining issues.

Chris: Sent emails, so did Sandro after the task force meeting.

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

<csma> (notes from the PS TF)

Chris: Requiring whitespace around syntactic infixes.
... Fixed a bug Sandro found.
... Suggestion to use commas between arguments.

Sandro: String literals as in Turtle/C: backslash.
... Comments: C++ style as shorthand for metadata comments.
... suffix 'd' for decimal numbers.

<AxelPolleres> +1 to without suffix decimal

<AxelPolleres> ... as default

Jos: Why not always decimal (without need for suffix).
... as in Turtle and other languages.

Sandro: A little more error-prone but also more convenient.

<sandro> sandro: Okay, no "d" required. default to decimal.

<josb> http://www.w3.org/TeamSubmission/turtle/#sec-tutorial

Jos: For double you use "e" as in Turtle.

Christian: Decisions for potential future dialects?

Sandro: Controversial discussion about named-argument infix.

<sandro> hasValue as keyword replacement for "->"

Sandro: proposed "::" but Michael later objected.

<josb> Jos: and let's drop floats from the shortcut syntax

<DaveReynolds> Seems rather verbose, but I wouldn't formally object.

<ChrisW> MK proposed using hasValue, member, and subclassOf instead of ->, #, and ##

Harold: I also think: too verbose!

Axel: Why not simply write triples like in N3?

<AxelPolleres> hmmm, if replacing a[b->c] a b c .

<AdrianP> writing triples is not a readable language

<ChrisW> harold, would you object to hasValue, etc?

<AxelPolleres> Adrian, I think I disagree.

<ChrisW> +1 extend

<AxelPolleres> N3, SPARQL, Turtle are pretty readable.

<AxelPolleres> parentheses?

<AxelPolleres> (a b c)

Harold: I think "hasValue" is not acceptable, since we use symbols, not keywords, for other central PS constructs.

<AxelPolleres> curly brackets to get even closer? { a b c } ?

Christian: Syntax for frames are a central remaining issue.

<AxelPolleres> Anything against curly brackets?

Sandro: Frames are useful when they are fully available.

<josb> me

Christian: Why not different syntaxes for frames?

<AdrianP> curly brackets are often used to denote modules

<AxelPolleres> sorry, seems I dropped out (telephone error)

<ChrisW> how are curly brackets different from []

<csma> a[b>c]

Axel: Curley brackets would make it more similar to Turtle.

<AxelPolleres> { a b c } is valid Turtle, a[b c] not

<sandro> a[ b -> x + 2 ]

<AxelPolleres> { a b x + 2 }

<AdrianP> looks like a list

Christian: Matter of taste.

Jos: Matter of implementability.

<AxelPolleres> Adrian... not anymore, if you have { a b c . a c d }

<sandro> http://lists.w3.org/Archives/Public/public-rif-wg/2009Feb/0114.html

<AxelPolleres> Where I want to get is... let's use/allow Turtle instead of the current slot syntax.

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

<josb> so, we can have {a, b, c} :)

<AxelPolleres> josB: baeh :-b

Christian: PS is not normative, so suggest not having style discussions.

Sandro: Two reasons for PS.

<AxelPolleres> I guess we have to solve the ambiguity of function calls issue in SPARQL as well.

<AxelPolleres> but we will quite sure stick with a Turtle style syntax.

<AdrianP> changing it now means a lot of extra effort

<AdrianP> all test cases and use case examples need to be updated

<sandro> No Adrian -- the test cases can use multiple syntaxes, as we agreed.

Sandro: PS1 would be the PS we have in use cases.

<ChrisW> aob?

Sandro: there could be PS2 for different purposes. Etc.

<ChrisW> we need to stop

Axel: Like push toward Turtle to get compatibility RIF and SPARQL.

<ChrisW> ACTION: axel to write a paragraph on ES-safeness in Core [recorded in http://www.w3.org/2009/03/10-rif-minutes.html#action05]

<trackbot> Created ACTION-715 - Write a paragraph on ES-safeness in Core [on Axel Polleres - due 2009-03-17].

<ChrisW> adjounred

- DRAFT -

RIF Telecon 10-Mar-09

10 Mar 2009

Attendees

Contents

Admin

Safeness and termination

Summary of Action Items

Scribe.perl diagnostic output