Admin

<ChrisW> PROPOSED: accept last weeks minutes

<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/att-0128/2008-06-17-rif-minutes.html

<ChrisW> RESOLVED: accept last weeks minutes

Liason

ChrisW: Received message from Mismo re a serialization format

Christian: referring to the Atom syndication format

Sandro: not clear how it relates to us

Christian: MISMO's current assumption is that they will extend RIF but waiting for PRD and stable BLD, also looking at multiple other possibilities
... Initially used to PR style, but when looked at BLD realized they do have need for things like integrity rules

Adrian: liason to HCLSG, meeting on Thursday

F2F11

<sandro> http://www.w3.org/2002/09/wbs/38457/f2f11dates/

Sandro: some results in but need answers, ideally today, from others especially editors

Current surviving date is 26/27 Sep (Fri/Sat)

ChrisW: sounds like our provisional date

Sandro: seems to be a preference for NY over Cambridge

Action review

ACTION-532 complete

ACTION-531 complete

ACTION-529 pending discussion

ACTION-527 done

<AxelPolleres> yes!@

<AxelPolleres> DTB doesn't talk about BASE

<AxelPolleres> I assumed this to be in BLD.

Discussion on action-526, action to put explanation in DTB re: URI base directive, syntax is in BLD already

Axel: not clear why this relates to DTB
... other abbreviations fitted in here because they related to constants and symbol spaces

Michael: this also relates to constants

<ChrisW> ACTION: axel to add explaination of relative IRIs wrt base directive to DTB shortcuts [recorded in http://www.w3.org/2008/06/24-rif-minutes.html#action01]

ACTION-526 now complete

<Harold> Axel, "While there is a RIF-BLD element tag for the Import directive, there are none for the Prefix and Base directives (they are represented directly in the underlying XML).

<Harold> "

ACTION-522 complete

ACTION-521 continued, Jie sent a message to the wg (message was blocked, Sandro has freed it)

ACTION-518 complete

Michael: FLD just need schema from Harold

Harold: finish BLD first, working on metadata and identifiers, aim for deadline of Friday

<ChrisW> ACTION: chris to create f2f11 wiki page [recorded in http://www.w3.org/2008/06/24-rif-minutes.html#action02]

<trackbot> Created ACTION-534 - Create f2f11 wiki page [on Christopher Welty - due 2008-07-01].

ACTION-515 completed

Axel: status of DTB - acted on comments from Jos and Harold. Wherever didn't reach agreement marked as editor note.
... only thing left is the action today (URI base and relative URIs) plus the action with the OWL-WG
... these aren't needed for WD
... so just update the description of shortcuts
... casting, rif:iri to/from string, there is now a strawman in there
... and there is an editors note linking this to issue-61

ACTION-487 complete

<Harold> http://www.w3.org/2005/rules/wiki/BLD#Alphabet_of_RIF-BLD

ChrisW: BLD has been updated (see Harold link) to just have list of datatypes
... point is that DTB in the long run will include new datatypes which are not automatically added to BLD

Axel: so same story for predicates and functions, where are those going to be listed?

ChrisW: want the BLD/DTB document relation to be easy to maintain. So BLD picks datatypes and DTB lists all the required predicates and functions for the selected datatypes.

Michael: just refer to the DTB section rather than name each predicate/function separately.

<Harold> If BLD refers to (sub)sections of DTB, then of course the version/date of DTB needs to be noted in BLD.

<Harold> (DTBs (sub)sections could change.)

ChrisW: issue is ease of maintenance over time.

Michael: add sections, not add functions to sections.

<AxelPolleres> I don't understand "The alternative is [...] to do as we do it now." ...

ChrisW: can add to list of datatypes but not functions and predicates for already defined datatypes.

Sandro: BLD refers to particular versions of DTB and lists any exceptions?

Axel: easiest thing would be for BLD to list the DTB sections.

<josb> +1 BLD document should indeed say which builtins it requires

<josb> (+1 was to Axel's suggestion)

ChrisW: organize the relation via the datatypes, the set of predicates and functions for a particular datatype is frozen
... so when BLD goes to LC those fn and preds in DTB are frozen from then on
... organize by section for each dialect makes DTB unmaintainable as the dialects increase

<josb> builtins may be defined for multiple datatypes

<GaryHallmark> string comparison predicates need work before you freeze anything!

ChrisW: so just add "and all associated builtin fns and preds"

Michael: issue that "associated", "mentioned" are not precise enough

<josb> numerics are not on one particular datatype!

Axel: consider compare on strings, that returns an integer, so there are cross dependencies on datatypes

<GaryHallmark> we should change string compare to work like numeric compare and date compare

Gary: tangentially the string, numeric and date comparison operators should all work the same

Jos: don't think it is possible to categorize the builtins by datatype e.g. casts, numeric functions

Sandro: or could have DTB have an appendix defining particular profiles

Michael: have dialects support all of DTB

Axel: some dialects could restrict the list, e.g. Core might be all of DTB minus specific exceptions

<AdrianP> +1 for Michael

<Zakim> GaryHallmark, you wanted to ask about adding string comparison predicates

<josb> Michael's suggestion works for me

<ChrisW> f2f10 resolution: RESOLVED: DTB will provide the menu of datatypes and builtins which dialects can use, by reference, when they state which datatypes and builtins must be supported by implementations.

<josb> yes, the reference needs to be dated!

ChrisW: so is the idea that BLD will reference a specific dated version of DTB and the entire set of datatypes and builtin fns and predicates in that version?

<josb> use date, not version number

Sandro: normally would refer by date but if we want to allow non-significant editorial changes then would have to make up some version numbering scheme

ChrisW: alt is to explicitly list all of this in an appendix in the dialect, that would reduce DTB maintenance overhead

<Harold> We could cross-refer between RIF docs using (date-containing!) URLs such as http://www.w3.org/TR/2006/WD-rif-ucr-20060710/

Jos: why not use dates?

ChrisW: want to be able to make changes to DTB which don't affect the list of builtins with breaking the link from BLD

Sandro: while BLD is in last call DTB will go through a couple of revisions, impact of that is unclear

ChrisW: decision at f2f was that DTB is a catalog, the dialect selects from DTB as a menu.

Gary: in practice all dialects are likely to share all datatypes

ChrisW: the point is to not change BLD while it is in last call

<csma> boolean

Sandro: need some stability here
... solution here is to have named profiles of datatypes and builtins, the dialects reference the profiles

<sandro> Chris: We are trying to allow DTB to be change after freezing BLD.

Axel: make changes in DTB in a separate document

<Harold> We could distinguish a 'basic DTB' part which can be frozen along with BLD Last Call. Then BLD needs to refer only to that basic DTB part. Both could later co-evolve.

Sandro: so that DTB is just DTB for BLD

<sandro> Axel: Let's freeze DTB as DTB-FOR-BLD. if PRD wants something else, it has to define its diff from this.

<csma> that is usable, but that makes DTB much less useful

Sandro: so proposal is that DTB is frozen as BLD is frozen, any changes needed to DTB are made elsewhere

<sandro> Axel's Proposal == DTB gets frozen at the same time at BLD, we can't change DTB going forward. If you need something different, you have to do a reference-with-diffs.

Harold:We could distinguish a 'basic DTB' part which can be frozen along with BLD Last Call. Then BLD needs to refer only to that basic DTB part. Both could later co-evolve.

<AxelPolleres> Harold, that is the same as listing all the preds and funcs from DTB which BLD is using explicitly.

ChrisW: that's basically Sandro's named profile proposal

<AxelPolleres> I see no problem with that either.

<sandro> Sandro's Proposal == DTB includes in an appendex a Frozen "Profile #1" which is the set of datatypes and builtings that BLD uses.

<AdrianP> spliting into several places where builtins and datatypes are defined would make it very hard for the user to use RIF

Harold: less happy with current proposal where deltas go in the dialect document, dilutes the use of DTB (and FLD) as a unifying force across the dialects

<AxelPolleres> I assume that core has less.

<AdrianP> it might also lead to a maintenance problem if RIF grows and we have many dialects

Christian: the unifying force is core

Gary: are there specific datatypes currently in DTB which would not go in core?

Christian: don't see reason it should be different, but don't see a reason to freeze DTB wrt to BLD, if freeze it should be wrt Core

<sandro> <sandro> Sandro's Proposal == DTB includes in an appendex a Frozen "Profile #1" which is the set of datatypes and builtings that BLD uses.

<AxelPolleres> E.g.: if core is only datalog, then I don't see much need for built-ins to be in Core.

<GaryHallmark> I note that nobody offered an example of a DTB datatype that would not be in Core

<Harold> DTB can play the role of a "unifying force" pulling together all of the RIF dialects. This should not be given up just to simplify cross-referencing between RIF docs. See Sandro's Proposal and my one above.

Axel: why define the profile in DTB, why not just list in appendix in the dialect document.

Sandro: because the profile may be shared, putting it in DTB enables that

Axel: so in that case let the other dialects say it uses the same datatypes and builtins as BLD

<sandro> PROPOSAL-3: BLD includes a frozen list of datatypes+builtings, and any dialect which wants to use it, can refer to it there (instead of a named profile in DTB)

Michael: object to putting big appendix in the dialects

<AxelPolleres> Ad "Michael and Axel have to negotiate who does the work": Micheal... let's just say Harold does it! ;-) just kiddin', Harold.

<AxelPolleres> I do not object to any of the two, I am fine with freezing DTB and also fine with explicitly enumerating preds and funcs in BLD.

<sandro> PROPOSAL-4: BLD refers to DTB by dated version.

<Harold> Axel, it's more a matter of avoiding redundancy to simplify maintenance.

<AxelPolleres> I only object to adding additional "profiles" to DTB.

<AdrianP> maintenance is a problem, e.g. in BLD rif:text is marked at risk in PRD it is not

<csma> can you repeat proposal 1 and 2

<sandro> PROPOSAL-4: BLD refers to DTB by dated version. (if dialects need other things, they refer to new dated versions. BLD still refers to old one)

<sandro> PROPOSAL-1 (Axel's Proposal) == DTB gets frozen at the same time at BLD, we can't change DTB going forward. If you need something different, you have to do a reference-with-diffs.

<sandro> PROPOSAL-2 (Sandro's Proposal )== DTB includes in an appendex a Frozen "Profile #1" which is the set of datatypes and builtings that BLD uses.

<sandro> PROPOSAL-4: BLD refers to DTB by version (date or number). (if dialects need other things, they refer to new dated versions. BLD still refers to old one)

<josb> date

<sandro> number

<AxelPolleres> number

<MichaelKifer> 0

<mdean> date

<GaryHallmark> number

<AdrianP> number

<csma> number

<mdean> should't it be by version URI?

<sandro> PROPOSED: BLD refers to DTB by version number. If/when dialects need other things, they refer to new versions. BLD still refers to old one.

<mdean> ... for the published document?

<AxelPolleres> ok, DTB was just renamed to "RIF Data Types and Built-Ins 1.0"

<AxelPolleres> yes, new versions are new documents.

<GaryHallmark> so, Axel, can you add string-not-equals, etc.???

<AdrianP> +1

<josb> +1

<AxelPolleres> It is marked with an Editor's note.

0

<LeoraMorgenstern> +1

<GaryHallmark> +1

<ChrisW> 0

<mdean> 0

<AxelPolleres> we have to discuss it.

<AxelPolleres> +1

<sandro> +0 nervous about it but I don't see a real problem

<Harold> 0

<sandro> RESOLVED: BLD refers to DTB by version number. If/when dialects need other things, they refer to new versions. BLD still refers to old one.

Finishing action review (!)

ACTION-482 complete

<AdrianP> can we use the versioning mechanism to refer to all other RIF documents?

<Harold> Lots of wiggle room for 1.0 :-)

<sandro> +1 extend

<Harold> +1

<AxelPolleres> +1

<csma> +1

<csma> what about action 484 (sorry if I insist)?

<Harold> A little bit of wiggle room can help us to co-evolove the two specs.

<GaryHallmark> BTW I created ISSUE-67 to track the string-less-than issue

[Non scribe] Humm that sounded like proposal 1 !

ACTION-505 closed

<trackbot> ACTION-505 Come up with style for "At Risk" comments in document. closed

ACTION-500 pending discussion

ACTION-498 closed

<trackbot> ACTION-498 Add text explaining external frames closed

ACTION-498 pending discussion

ACTION-506 pending discussion

ACTION-502 closed

<trackbot> ACTION-502 Put relative IRI handling, with base directive, in BLD closed

<Harold> I think we should also add the version number to BLD 1.0 so people can see that BLD 1.0 and DTB 1.0 are in sync.

ChrisW: don't expect the dialects to change
... FLD less clear but the changes we could imagine are unlikely to change the dialect defn