See also: IRC log
<csma> PROPOSED: accept minutes of telecon May 12
<csma> RESOLVED: accept minutes of telecon May 12
<ChrisW> discussing rdf:text
Axel mentions discussions and a proposal and a coming conference about rdf:text (?)
<ChrisW> external LC comments from SPARQL WG
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:
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
... 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
<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].
<ChrisW> close action-813
<trackbot> ACTION-813 Find clarification on year-from-duration from XPATH wg closed
<trackbot> ACTION-812 Define cast from xmlliteral to streing closed
<trackbot> ACTION-811 Check that all RIF datatypes have a canonical representation closed
<trackbot> ACTION-809 Respond to harolds comments closed
<Stella-MItchell> action-792 done
<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 ...
<trackbot> ACTION-774 Review FLD closed
<trackbot> ACTION-773 Review BLD closed
<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.
<trackbot> ACTION-771 Review DTB closed
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.
<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
<trackbot> ACTION-768 Review Core closed
<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.
<Stella-MItchell> Action-708 continued
<ChrisW> agreed - discuss later
<ChrisW> leave it open
<ChrisW> still pending
<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).
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
ChrisW: There were issues about
... 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
<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> 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
<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
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> MichaelKifer: it's that way already.
<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.
Sandro: Prefers 'append list' but not strongly
<sandro> PROPOSED: add append as a new list-builtin and remove ceiling of list indexes.
<AxelPolleres> 0 not sure whether not redundant still
<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.
<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  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 ?
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.
<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].
<csma> PROPOSED: Publish DTB as last call. draft, pending completion of all DTB actions
<ChrisW> good job, Axel!
<csma> RESOLVED: Publish DTB as last call. draft, pending completion of all DTB actions
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
<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?
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> 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.
<ChrisW> +1 (IBM)
<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
<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
<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
<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)
<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)