Admin

<csma> http://www.w3.org/2009/05/12-rif-minutes.html

<csma> PROPOSED: accept minutes of telecon May 12

<csma> RESOLVED: accept minutes of telecon May 12

Liaison

rdf:text

<ChrisW> rdf:text

<ChrisW> discussing rdf:text

Axel mentions discussions and a proposal and a coming conference about rdf:text (?)

<ChrisW> external LC comments from SPARQL WG

<ChrisW> s/RDFX/rdf:text/

Will have some impact (but only editorial) on RIF

Sandro: Not sure ... but worries about connections with how this maps back to RDF

Axel: If we come an agreement on a lexical form then there should be no problem ...

Christian: Question - is there any "at risk" things in there ?

Sandro: Every thing about rdf:text should marked at risk unless proven otherwise (Michael had strong opinions about that)

<AxelPolleres> I think we might want need to change

<AxelPolleres> "A constant in a particular RIF symbol space has the following presentation syntax:

<AxelPolleres> "literal"^^<symbolSpaceIri>"

Sandro: Might need to revert to RDF's plain literal ... but not sure at his stage

<AxelPolleres> to three different representations, i.e. not having rdf:text represented the way we do it now but only using the RDF literal representation.

Sandro: Might be more than syntax ... semantics may be also
... if we get rid of 'rdf:text' then we need to support special handling if RFD plain literal in all RIF dialects because they are not data types (RDF plain literals)

Christian: Then we need MichaelK's input

ChrisW: Don't understand the issue here

Sandro: Let me put it another way ... We would need to specify what RDF literals map to ... but what ?
... not clear ... but we need to be cautious there ... need a fallback position

MichaelK: If we can't use it then users must be aware that they's have to invent their own semantics

Sandro: Ok - let's just use 'rdf:text'

DaveReynolds: Just introduce the data type for

<csma> PROPOSED: rdf:text will be marked at risk in DTB

'rdf:text' and that could be the target of semantics

Sandro: No need to be more precise

<Zakim> AxelPolleres, you wanted to answer Dave

Christian: Cites SWC and DTB? where such issues might have an impact

<ChrisW> do we need an action here?

Axel: People did not like the lexical space with trailing @ ... need to explain

<csma> PROPOSED: rdf:text will be marked at risk in DTB

<sandro> +1

<ChrisW> +1

<DaveReynolds> +1

+1

<MichaelKifer> 0

<Harold> +1

<cke> 0

<AxelPolleres> 0

<AdrianP> +1

<csma> RESOLVED: : rdf:text will be marked at risk in DTB

<sandro> ACTION: axel mark rdf:text at risk in DTB [recorded in http://www.w3.org/2009/05/19-rif-minutes.html#action01]

<trackbot> Created ACTION-815 - Mark rdf:text at risk in DTB [on Axel Polleres - due 2009-05-26].

Action Review

<ChrisW> close action-813

<trackbot> ACTION-813 Find clarification on year-from-duration from XPATH wg closed

close action-812

<trackbot> ACTION-812 Define cast from xmlliteral to streing closed

close action-811

<trackbot> ACTION-811 Check that all RIF datatypes have a canonical representation closed

close action-809

<trackbot> ACTION-809 Respond to harolds comments closed

<Stella-MItchell> action-792 done

close action-792

<trackbot> ACTION-792 Add note in test case document that negative tests 'go down' and positive tests "go up" closed

<ChrisW> close action 810 (completed by Harold)

<ChrisW> close action-810 (completed by Harold)

<ChrisW> close action-810

<trackbot> ACTION-810 Draft a paragraph describing the status of the presentation syntax closed

<AdrianP> Core and PRD already have a modular schema. Only BLD would need to be refactored

<cke> I prefer to have a resolution to track the decision

<sandro> sandro: fine, as long as we have an editor's note saying that ...

close action-774

<trackbot> ACTION-774 Review FLD closed

close action-773

<trackbot> ACTION-773 Review BLD closed

close action-772

<trackbot> ACTION-772 Review swc closed

<sandro> PROPOSED: The LC drafts will have the 'flat' schemas, with an editors note saying we expect to refactor the schemas in the future (to use "include"), but do not expect to change which XML instance documents will be valid.

close action-771

<trackbot> ACTION-771 Review DTB closed

<cke> +1

<sandro> +1

+1

<ChrisW> +1

<Gary> +1

<AdrianP> 0

<DaveReynolds> 0

<mdean> 0

<Harold> 0.25

<MichaelKifer> 0

<AxelPolleres> +1

Harold: A flat XML scheme won't interfere with our design

<cke> XML instance documents will be preserved, it's our objective

<csma> RESOLVED: The LC drafts will have the 'flat' schemas, with an editors note saying we expect to refactor the schemas in the future (to use "include"), but do not expect to change which XML instance documents will be valid.

close action-769

<trackbot> ACTION-769 Review PRD closed

<AdrianP> yes we need to take care about the maintenance of the flat schemas which are mostly copy and paste

close action-768

<trackbot> ACTION-768 Review Core closed

close action-740

<trackbot> ACTION-740 Accomodate casting functions in a well defined manner closed

<Harold> A 'flattening' of schemas should NOT lead to any divergence between schemas in the same 'inheritance line' such as the FLD---BLD---Core line and the PRD---Core line.

<ChrisW> axel?

<Stella-MItchell> Action-708 continued

<ChrisW> agreed - discuss later

<ChrisW> leave it open

<ChrisW> still pending

Slot Names in Frames

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

<ChrisW> why not?

<cke> If slot names are not fixed strings, what can they be? Can someone give an example?

Christian: Summarizing GaryH's and DaveR's worries with respect to frames (non constant fields, wher variables/terms can occur)

<cke> Localized names of course make sense

MichaelK: Do not see the problem ... simply restrict it - Frames are general enough to express this

<cke> In most PR engines, the names are valid identifiers, which are composed of some specific characters

Christian: Need to translate a frame whose slot is a list (say) ... what does it mean ?

<AxelPolleres> "Mark rdf:text at risk in DTB" (ACTION-815) is done from my side (status now set to pending review)

MichaelK: It will be interpreted same way as done by the systems for which it makes sense to have such slots

<sandro> gary: it's a chore, but I think it's fine.

<cke> I will have to mangle the names. Can someone make a case why the names should be generalized?

GaryH: It is possible but a pain to handle such quirks

<ChrisW> did we deal with this: 1. PRD prohibits member (#) in rule heads. Core allows it. I think

<ChrisW> Core must follow PRD here.

DaveReynolds: Integers as slots in frames are not really an issue

Christian: Core does not have numbers at all

<sandro> The alphabet of the presentation language of RIF-Core is the alphabet of the RIF-BLD presentation language with the exclusion of the symbol ## (subclass) and the set of symbols ArgNames (used for named-argument uniterms).

<sandro> (quoting)

GaryH and Sandro: really ... what CORE does not have is subclasses not numbers

<Stella-MItchell> see section 2.3 in core too

Sandro: Confirms that numbers are in CORE but that class membership is not allowed in rule conclusions

Last Call publications

DTB

ChrisW: There were issues about lists
... prefers cons-like lists to numerical index

<DaveReynolds> +1 to put in append

Sandro: Indexed lists are useful for efficient insertion ...

<ChrisW> add an append function to DTB for lists

<ChrisW> ...instead of having numerical indexes that go past the end of the list

<sandro> Sandro: the reason for the rule about too-high-indexes being reduced is that it lets you use insert-before like append.

<Gary> I think append(list, element) = concatenate(list, make-list(element))

<AxelPolleres> There is a statement in DTB Sec 1.2.1:

<AxelPolleres> * rif:iri (http://www.w3.org/2007/rif#iri, ... ... ... A rif:iri

<AxelPolleres> constant must be interpreted as a reference to one and the same

<AxelPolleres> object regardless of the context in which that constant occurs.

<sandro> true, Gary

ChrisW: Issue is about what an IRI means

<AdrianP> there was also the question about naming of primitive datatypes

Axel: Objects to the relevance of this issue at that place in the DTB cocument

Sandro: Prefers omitting this explanation as it is confusing

DaveR: Is happy with dropping it as well

MichaelK: Could add that IRI's interpretation is not affected

ChrisW: Adding this comment in FLD would be also useful

MichaelK: Agreed

<ChrisW> Chris is shappy, too

Axel: Already dropped the text from the DTB document

<AxelPolleres> Here two more TODOs which are less clear:

<AxelPolleres> * Speaking of "primitive datatypes" should be avoided

<AxelPolleres> We call our datatypes "primitive" but this is not in compliance with

<AxelPolleres> http://www.w3.org/TR/xmlschema11-2/#dt-primitive

<AxelPolleres> since we also use "primitive" for what are actually "ordinary" datatypes following XSD. I suggest we just speak about datatypes.

<AxelPolleres> * in my BLD review, I suggested that the Base Directive should refer to *absolute* iri:

<AxelPolleres> "where iri is a unicode string in the form of an *absolute* IRI

<AxelPolleres> [RFC-3987]."

<AdrianP> I would propose to call it simple datatypes

<ChrisW> ACTION: axel rename "primitive" datatypes to datatypes [recorded in http://www.w3.org/2009/05/19-rif-minutes.html#action02]

<trackbot> Created ACTION-816 - Rename "primitive" datatypes to datatypes [on Axel Polleres - due 2009-05-26].

<sandro> agreed, iri in base should be absolute (absolutely)

<ChrisW> michael is back one issue

<sandro> MichaelKifer, I think XML has "complex types" not "complex datatypes". datatypes seems to be the same as "simple types"

<ChrisW> PROPOSED: extend meeting by 30 minutes

<Stella-MItchell> I can scribe at end

<csma> RESOLVED: extend meeting by 30 minutes

<AxelPolleres> http://www.w3.org/TR/xmlschema11-2/#primitive-vs-derived

<AxelPolleres> http://www.w3.org/TR/xmlschema11-2/#rf-defn

Discussion about nuances on data types and primitive types ... and whether adding an explanation confuses more

MichaelK: Ok let me think about how to rephrase this ...

<sandro> PROPOSED: base directive will take absolute IRI

<sandro> +1

<ChrisW> +1

<sandro> MichaelKifer: it's that way already.

<DaveReynolds> +1

+1

<AdrianP> +1

<csma> RESOLVED: base directive will take absolute IRI

<sandro> RESOLVED: base directive will take (or maybe already does take) absolute IRI

<sandro> ACTION: axel make sure base takes absolute IRI in DTB [recorded in http://www.w3.org/2009/05/19-rif-minutes.html#action03]

<trackbot> Created ACTION-817 - Make sure base takes absolute IRI in DTB [on Axel Polleres - due 2009-05-26].

<ChrisW> ACTION: axel to make base directive iris absolute [recorded in http://www.w3.org/2009/05/19-rif-minutes.html#action04]

<trackbot> Created ACTION-818 - Make base directive iris absolute [on Axel Polleres - due 2009-05-26].

<sandro> action-817 closed

<trackbot> ACTION-817 Make sure base takes absolute IRI in DTB closed

<AxelPolleres> ACTION-817 is done.

<AxelPolleres> ACTION-816 is done.

<csma> O

Sandro: Prefers 'append list' but not strongly

<sandro> PROPOSED: add append as a new list-builtin and remove ceiling of list indexes.

<AdrianP> +1

0

<ChrisW> 0

<Gary> +1

<mdean> +1

<sandro> +0.75

<cke> +1

<Harold> 0

<AxelPolleres> 0 not sure whether not redundant still

<DaveReynolds> +1

<sandro> RESOLVED: add append as a new list-builtin and remove ceiling of list indexes.

<csma> RESOLVED: : add append as a new list-builtin and remove ceiling of list indexes.

<MichaelKifer> 0

<ChrisW> ACTION: sandro to add append to DTB [recorded in http://www.w3.org/2009/05/19-rif-minutes.html#action05]

<trackbot> Created ACTION-819 - Add append to DTB [on Sandro Hawke - due 2009-05-26].

<csma> *PROPOSED:* Publish DTB as last call. draft.

<csma> *PROPOSED:* Publish DTB [4] as last call. draft, pending completion of all actions

MichaelK: There is an issue about short names ... need to check with Axel ... should be moved out

Axel: Not see a problem

<ChrisW> "The short name of a symbol space is an NCName, typically the character sequence after the last '/' or '#' in the symbol space IRI (similar to the XML local name part of a QName). "

MichaelK: Problem is with symbol space for short names

Axel: Where do you suggest we put them ?

MichaelK: They should not be in the definition of the symbol space ... the problem is that short names in BLD and FLD do not coincide then

ChrisW: Do not understand what the issue is

Christian: Nothing references them - why do we have them ?

ChrisW: They are not formal - just a handy thing

Axel: Need them for other sections

ChrisW: Just list all the datatypes and their short names there

Axel: We can do why MichaelK suggests cleaning up the definition

MichaelK: Yes but move them to the preamble

Christian: Are any of these short names different from the names of the datatypes ?

Axel: No

ChrisW: I still do not understand the issue ! they are just handy things

MichaelK: Yes but they need to have the same specs with respect to to symbol spaces in both FLD and DTB - they do not now

<DaveReynolds> So put Chris' proposed text in 1.3

MichaelK: We need them only for datatypes .. just move them to the section there

ChrisW: Finds this inconvenient

because of editorial reasons ... why makes it longer just to match another document

<ChrisW> scribe: Stella-MItchell

<ChrisW> ACTION: axel to move the shortnames out of the definition of symbol spaces, and remove shortnames for iri and local [recorded in http://www.w3.org/2009/05/19-rif-minutes.html#action06]

<trackbot> Created ACTION-820 - Move the shortnames out of the definition of symbol spaces, and remove shortnames for iri and local [on Axel Polleres - due 2009-05-26].

Christian: Michael, is this OK?

MichaelK: Introduces forward reference

ChrisW: We can make acceptance of document contingent on resolving this

<csma> PROPOSED: Publish DTB as last call. draft, pending completion of all DTB actions.

<sandro> +1

<LeoraMorgenstern> I can volunteer.

<csma> PROPOSED: Publish DTB as last call. draft, pending completion of all DTB actions to the of Leora

<ChrisW> ACTION: leora to review pending DTB actions (815-820) [recorded in http://www.w3.org/2009/05/19-rif-minutes.html#action07]

<trackbot> Created ACTION-821 - Review pending DTB actions (815-820) [on Leora Morgenstern - due 2009-05-26].

<sandro> +1

<cke> +1

<ChrisW> +1

<Harold> +1

<MichaelKifer> +1

<AdrianP> +1

<LeoraMorgenstern> +1

+1

<DaveReynolds> +1

<Gary> +1

<csma> PROPOSED: Publish DTB as last call. draft, pending completion of all DTB actions

<mdean> +1

<ChrisW> good job, Axel!

<csma> RESOLVED: Publish DTB as last call. draft, pending completion of all DTB actions

Core

Changhai: I reviewed Core and I saw a response from DaveR. The content looks fine to me

<AdrianP> do we need to make change with respect to class membership in Core?

<AdrianP> The Terms of RIF-Core are the terms of RIF-BLD with the exclusion of subclass terms and of terms with named arguments.

<DaveReynolds> Adrian - I think it is currently consistent with the resolution

<AdrianP> ok, great

<DaveReynolds> What's inconsistent at the moment?

<ChrisW> stella, your scribing is coming out as "emotes"

<ChrisW> those don't get included in the record

<ChrisW> (lines starting with *)

<StellaMitchell> ok, I typed them as emotes, but shouldn't have

<ChrisW> tnx

<StellaMitchell> alphabet of RIF-Core need to be updated to say that # is excluded

<DaveReynolds> Stella - # is not excluded, it is only excluded in the head which is the resolution, and what Core says

<StellaMitchell> oh, right

<AdrianP> yes, Core says Equality terms and class membership terms cannot occur in rule conclusions -- they are allowed only in rule premises.

ChrisW: Issue about binding patterns for lists, from Jos?

<DaveReynolds> http://lists.w3.org/Archives/Public/public-rif-wg/2009May/0069.html

Sandro: Jos proposed, and GaryH and Sandro seconded that binding patterns be changed, was that change made?

GaryH: There is still an editor's note

Christian: To disallow using equality builtins to bind one variable

<sandro> # the external predicate pred:list-contains has the valid binding pattern (b, u).

<sandro> PROPOSED: following editor's note in Core 6.1, all of the binding patterns with "u" for the equality predicates will be removed.

<AxelPolleres> Action-820 is done, cf. http://www.w3.org/2005/rules/wiki/DTB#Symbol_Spaces

<sandro> This leaves just: pred:iri-string and pred:list-contains as having "u" binding patterns.

Sandro: I think you can write much better rules with binding patterns b,u for list contains

Christian: GaryH, is it OK with you?

<sandro> gary: I see list-contains as (b, u) as a challenge, but I think it's doable.

<sandro> PROPOSED: following editor's note in Core 6.1, all of the binding patterns with "u" for the equality predicates will be removed. (this leaves only pred:iri-string and pred:list-contains as (b, u))

<sandro> +1

<ChrisW> +1

<DaveReynolds> +1

<Gary> +1

<mdean> +1

<sandro> RESOLVED: following editor's note in Core 6.1, all of the binding patterns with "u" for the equality predicates will be removed. (this leaves only pred:iri-string and pred:list-contains as (b, u))

GaryH: I addressed Stella's comments on Core. Jos still has to address something in the safeness section.

Stella: I think Jos addressed the comments I made on the safeness section.

GaryH: Core, definition of safeness in section 6.1, 4th bullet point...
... confused by 2 c-one subscripts?

DaveR: No, it is c-one to c-el

ChrisW: some wiki skins result in a confusing display of these subscripts

<Harold> f1, ..., fl

Stella: My comment was on why c-el was not referred to in the rest of the definition - Jos explained that part

<csma> PROPOSED: Publish Core as last call draft, pending completion of Core actions

<sandro> ACTION: Gary to change subscript "l" in 6.1 to something else (not so confused with "1") and have Jos proof-read the change. [recorded in http://www.w3.org/2009/05/19-rif-minutes.html#action09]

<trackbot> Created ACTION-822 - Change subscript "l" in 6.1 to something else (not so confused with "1") and have Jos proof-read the change. [on Gary Hallmark - due 2009-05-26].

ChrisW: We need actions for the updates still to be done

<AxelPolleres> Can we close 816/818, they're done.

DaveR: I just updated the binding patterns

ChrisW: Who will review the recent core changes?

Christian, Sandro: Jos will still review core

<csma> PROPOSED: Publish Core as last call draft, pending completion of Core actions.

<sandro> +1

<DaveReynolds> +1

<ChrisW> +1 (IBM)

<mdean> +1

<AdrianP> +1

<StellaMitchell> +1

<Harold> +1

<cke> +1

<MichaelKifer> +1

<AxelPolleres> +1

<LeoraMorgenstern> +1

<Gary> +1

<csma> RESOLVED: : Publish Core as last call draft, pending completion of Core actions.

Sandro: I'm debating going to management with having it be contingent on LC decisions being made next week

BLD

<AxelPolleres> need to go.

AxelP: I reviewed BLD

Harold: I and Michael addressed Axel's comments

AxelP: I didn't have time yet to check the implementation of the review

<ChrisW> ACTION: axel review changes to BLD [recorded in http://www.w3.org/2009/05/19-rif-minutes.html#action10]

<trackbot> Created ACTION-823 - Review changes to BLD [on Axel Polleres - due 2009-05-26].

Christian: I also reviewed BLD, and just have one question about mapping of the condition language to XML
... empty argument element, rather than no element, when a predicate, function. built-in has no arguments

Christian: Is this OK? GaryH, Changhai?

<cke> yes ok for me

GaryH: Yes

Changhai: Yes

<cke> so this should be specified in core.

Christian: Michael, question about type (anyURI or rif:iri) of locator for import
... doesn't reflect what was decided at F2F13

MichaelK: I think the minutes from F2F13 are incorrect - the 2 resolutions are inconsistent with each other

<MichaelKifer> <"a"^^anyURI>

<csma> RESOLVED: In the XML syntax (for Core, BLD, PRD), the xml-schema type of both arguments to import is an anyURI -- NOT rif Const element(s).

<csma> RESOLVED: In RIFPS, we'll use <...> to delimit the IRI arguments to Import, Base, Prefix. (This syntax is the same as rif:iri Consts, but you can tell by the context.)

Christian: My comments are about the XML syntax

MichaelK: Ok, I didn't understand that before

<csma> PROPOSED: Publish BLD as 2nd LC draft

<ChrisW> +1 (IBM)

<sandro> +1

<AdrianP> +1

<StellaMitchell> +1

<Harold> +1

<cke> +1

<MichaelKifer> +1

<AxelPolleres> +1 (pending review of my changes being implemented.)

<DaveReynolds> +1 (pending Axel's review)

<csma> PROPOSED: Publish BLD as a second Last Call, pending axel review that his request have been implemented

<csma> RESOLVED: : Publish BLD as a second Last Call, pending axel review that his request have been implemented

<sandro> second last call means last call, but it happens to be the second time it's been at last call.

<sandro> right, LeoraMorgenstern --- "last call" just means "we think we're done", but you can always be corrected and find out you weren't really done.

<ChrisW> good job harold/michael

<ChrisW> good job dave, gary, adrian (with Core)

<DaveReynolds> and especially Jos! (for Core)

AOB

<ChrisW> adjourned