RIF F2F13 Minutes, 16 April 2009

13:41:33 <josb> this one is safe, but not strongly safe: http://www.w3.org/2005/rules/wiki/Core_Safeness

Jos de Bruijn: this one is safe, but not strongly safe: http://www.w3.org/2005/rules/wiki/Core_Safeness ←

13:42:10 <cke> <axel> I would just make a note, give a name, ...

<axel> I would just make a note, give a name, ... ←

13:43:01 <ChrisW> cke, use this syntax:

Christopher Welty: cke, use this syntax: ←

13:43:09 <ChrisW> axel: I would just make a note

Axel Polleres: I would just make a note [ Scribe Assist by Christopher Welty ] ←

13:43:18 <ChrisW> (use : not <>)

Christopher Welty: (use : not <>) ←

13:43:27 <cke> csma: if some engines won't acept the rulesets which are not strongly safe

Christian de Sainte Marie: if some engines won't acept the rulesets which are not strongly safe ←

13:44:18 <cke> axel: we can put it as non normative, we need to provide a way to hav a claim

Axel Polleres: we can put it as non normative, we need to provide a way to hav a claim ←

13:46:46 <cke> csma: i do not understand the impact of the restriction. We need to understand the exact impacts

Christian de Sainte Marie: i do not understand the impact of the restriction. We need to understand the exact impacts ←

13:48:05 <cke> hb: in BLD, there are notions of conformance, strong and weak

Harold Boley: in BLD, there are notions of conformance, strong and weak ←

13:48:37 <cke> hb: we could have a default conformance notion

Harold Boley: we could have a default conformance notion ←

13:49:00 <AxelPolleres> THat one would nopt be strongly safe: http://www.w3.org/2005/rules/wiki/Chaining_strategy_numeric-add_2

Axel Polleres: THat one would nopt be strongly safe: http://www.w3.org/2005/rules/wiki/Chaining_strategy_numeric-add_2 ←

13:49:52 <GaryHallmark> dave: strong safety should not be normative, just informative

Dave Reynolds: strong safety should not be normative, just informative [ Scribe Assist by Gary Hallmark ] ←

13:50:11 <GaryHallmark> sense of room: many agreeing with Dave

Gary Hallmark: sense of room: many agreeing with Dave ←

13:50:17 <cke> chrisw: what does informative means? (if we put this as informative)

Christopher Welty: what does informative means? (if we put this as informative) ←

13:51:32 <ChrisW> PROPOSED: strong safety would be an informative note (not at risk) in Core, changing previous resolution

PROPOSED: strong safety would be an informative note (not at risk) in Core, changing previous resolution ←

13:51:39 <AxelPolleres> isn't "non-normative" the right word to be used in W3C docs?

Axel Polleres: isn't "non-normative" the right word to be used in W3C docs? ←

13:52:14 <AdrianP> +1

13:52:15 <cke> +1

+1 ←

13:52:17 <GaryHallmark> +1

13:52:19 <ChrisW> RESOLVED: strong safety would be an informative note (not at risk) in Core, changing previous resolution

RESOLVED: strong safety would be an informative note (not at risk) in Core, changing previous resolution ←

13:52:28 <DaveReynolds> +1

13:52:44 <stabet> +1

Said Tabet: +1 ←

13:52:49 <AxelPolleres> +1

13:52:58 <Harold> +1

Christian de Sainte Marie: http://www.w3.org/2005/rules/wiki/Lists#List_Builtins ←

13:53:08 <ChrisW> action: axel to draft E-S safety and make informative instead of at-risk

ACTION: axel to draft E-S safety and make informative instead of at-risk ←

13:53:08 <trackbot> Created ACTION-749 - Draft E-S safety and make informative instead of at-risk [on Axel Polleres - due 2009-04-23].

Trackbot IRC Bot: Created ACTION-749 - Draft E-S safety and make informative instead of at-risk [on Axel Polleres - due 2009-04-23]. ←

13:53:59 <cke> csma: 10mn on list built-ins

Christian de Sainte Marie: 10mn on list built-ins ←

13:54:15 <csma> http://www.w3.org/2005/rules/wiki/Lists#List_Builtins

13:56:48 <csma> q?

Harold Boley: http://www.w3.org/2005/rules/wiki/FLD#Alphabet ←

13:58:34 <cke> sandro: we discussed the built-in in the wiki page

Sandro Hawke: we discussed the built-in in the wiki page ←

14:00:36 <sandro> RRSAgent, pointer?

Sandro Hawke: RRSAgent, pointer? ←

14:00:36 <RRSAgent> See http://www.w3.org/2009/04/16-rif-irc#T14-00-36

RRSAgent IRC Bot: See http://www.w3.org/2009/04/16-rif-irc#T14-00-36 ←

14:00:41 <cke> kifer: do we add them to prd, or to core?

Michael Kifer: do we add them to prd, or to core? ←

14:03:48 <DaveReynolds> q+

Dave Reynolds: q+ ←

14:04:05 <Harold> RIF-FLD reserves the following symbols for standard aggregate functions: min, max, count, avg, sum, prod, set, and bag.

Harold Boley: RIF-FLD reserves the following symbols for standard aggregate functions: min, max, count, avg, sum, prod, set, and bag. ←

14:04:48 <Harold> http://www.w3.org/2005/rules/wiki/FLD#Alphabet

14:06:22 <AxelPolleres> What about get-first(L), get-last(L), get-element-at(L,I)?

Axel Polleres: What about get-first(L), get-last(L), get-element-at(L,I)? ←

14:06:45 <DaveReynolds> Axel - exactly what I was on the queue to mention

Dave Reynolds: Axel - exactly what I was on the queue to mention ←

14:07:42 <cke> we discuss if we add set and bag. set removes duplicates

we discuss if we add set and bag. set removes duplicates ←

14:09:23 <AxelPolleres> q+

Axel Polleres: q+ ←

14:09:32 <DaveReynolds> Could identify function by anyURI

Dave Reynolds: Could identify function by anyURI ←

14:09:44 <DaveReynolds> Horrid but legal

Dave Reynolds: Horrid but legal ←

14:11:00 <stabet> L1, L2)

Said Tabet: L1, L2) ←

14:11:27 <sandro> who is scribe?

Sandro Hawke: who is scribe? ←

14:11:33 <stabet> sorry I meant to say: how about adding is-sublist?

Said Tabet: sorry I meant to say: how about adding is-sublist? ←

14:11:47 <cke> i'm scribe

i'm scribe ←

14:12:35 <cke> we discuss some other builtins: getFirst, getLast, getElement, etc

we discuss some other builtins: getFirst, getLast, getElement, etc ←

14:12:59 <Harold> If bag(L) returns L' in (canonical) lexicographic -- rather than random -- order (ie sorted), then equal(bag(L1)bag(L2)) can be computed in linear time.

Harold Boley: If bag(L) returns L' in (canonical) lexicographic -- rather than random -- order (ie sorted), then equal(bag(L1)bag(L2)) can be computed in linear time. ←

14:13:27 <sandro> get(-1) == getLast,   get(0) == getFirst

Sandro Hawke: get(-1) == getLast, get(0) == getFirst ←

14:15:13 <sandro> chrisw: So we can't do map and reduce (which we'd love) without being able to pass functions, which we can't do.

Christopher Welty: So we can't do map and reduce (which we'd love) without being able to pass functions, which we can't do. [ Scribe Assist by Sandro Hawke ] ←

14:15:48 <DaveReynolds> Could pass an anyURI which identifies the function. Not nice but could be defined in a workable way.

Dave Reynolds: Could pass an anyURI which identifies the function. Not nice but could be defined in a workable way. ←

14:17:10 <cke> do we need sort?

do we need sort? ←

14:21:53 <cke> there may be a solution to implement map/reduce. we can pass a code for a function

there may be a solution to implement map/reduce. we can pass a code for a function ←

14:22:10 <cke> 15mn break

15mn break ←

14:23:49 <sandro> reduce(function, iterable[, initializer])¶

Sandro Hawke: reduce(function, iterable[, initializer])¶ ←

14:23:49 <sandro>     Apply function of two arguments cumulatively to the items of iterable, from left to right, so as to reduce the iterable to a single value. For example, reduce(lambda x, y: x+y, [1, 2, 3, 4, 5]) calculates ((((1+2)+3)+4)+5). The left argument, x, is the accumulated value and the right argument, y, is the update value from the iterable. If the optional initializer is present, it is placed before the items of the iterable in the calculation, and serves as a def

Sandro Hawke: Apply function of two arguments cumulatively to the items of iterable, from left to right, so as to reduce the iterable to a single value. For example, reduce(lambda x, y: x+y, [1, 2, 3, 4, 5]) calculates ((((1+2)+3)+4)+5). The left argument, x, is the accumulated value and the right argument, y, is the update value from the iterable. If the optional initializer is present, it is placed before the items of the iterable in the calculation, and serves as a def ←

14:23:50 <sandro> ault when the iterable is empty. If initializer is not given and iterable contains only one item, the first item is returned.

Sandro Hawke: ault when the iterable is empty. If initializer is not given and iterable contains only one item, the first item is returned. ←

14:39:07 <ChrisW> dave?

(No events recorded for 15 minutes)

Christopher Welty: dave? ←

14:39:18 <ChrisW> zakim, who is on the phone?

Christopher Welty: zakim, who is on the phone? ←

14:39:18 <Zakim> On the phone I see DaveReynolds, MIT-G631

Zakim IRC Bot: On the phone I see DaveReynolds, MIT-G631 ←

14:39:19 <Zakim> MIT-G631 has ChrisW, csma, Harold, MichaelKifer, AdrianP, SaidTabet, cke, johnhall, AxelPolleres, josb, GaryHallmark, StellaMitchell

Zakim IRC Bot: MIT-G631 has ChrisW, csma, Harold, MichaelKifer, AdrianP, SaidTabet, cke, johnhall, AxelPolleres, josb, GaryHallmark, StellaMitchell ←

14:43:07 <ChrisW> Scribe: StellaMitchell

(Scribe set to Stella Mitchell)

14:43:38 <josb> isLiteralOfType

Jos de Bruijn: isLiteralOfType ←

14:43:43 <StellaMitchell> Jos: problem is how to identify datatypes, this is a result of the above predicate

Jos de Bruijn: problem is how to identify datatypes, this is a result of the above predicate ←

14:44:23 <StellaMitchell> ...the 2nd arg of the predicate is supposed to be the identifier of the datatype, so we need to decide what is a reasonable identifier for datatypes

...the 2nd arg of the predicate is supposed to be the identifier of the datatype, so we need to decide what is a reasonable identifier for datatypes ←

14:44:47 <josb> isLiteralOfType("1"^^integer, xs:int)

Jos de Bruijn: isLiteralOfType("1"^^integer, xs:int) ←

14:45:24 <StellaMitchell> ..rif:iri is one possibility, but it is kludgy. Above example illustrates...

..rif:iri is one possibility, but it is kludgy. Above example illustrates... ←

14:46:00 <DaveReynolds> That's the part of the point of the predicate, it should reflect the actual datatype map of the implementation. Why is that a problem?

Dave Reynolds: That's the part of the point of the predicate, it should reflect the actual datatype map of the implementation. Why is that a problem? ←

14:46:12 <StellaMitchell> ...different results depending on whether or not you support the datatye

...different results depending on whether or not you support the datatye ←

14:46:50 <josb> p(?x) :- isLiteralOfType("1"^^int, ?x)

Jos de Bruijn: p(?x) :- isLiteralOfType("1"^^int, ?x) ←

14:47:39 <StellaMitchell> Jos: in the above example need to check all possible assignments of ?x

Jos de Bruijn: in the above example need to check all possible assignments of ?x ←

14:48:07 <DaveReynolds> It would return false not an error so that rule would be ok.

Dave Reynolds: It would return false not an error so that rule would be ok. ←

14:48:08 <StellaMitchell> ...for some values, it will be unspecified according to DTB and good practice would be to raise an error

...for some values, it will be unspecified according to DTB and good practice would be to raise an error ←

14:48:54 <StellaMitchell> mk: join of two predicates?

Michael Kifer: join of two predicates? ←

14:48:58 <MichaelKifer> p(?x) :- q(?x), isLiteralOfType("1"^^int, ?x)

Michael Kifer: p(?x) :- q(?x), isLiteralOfType("1"^^int, ?x) ←

14:49:26 <DaveReynolds> We already have invisible extensions surely, if you add predicates existing rule sets potentially break.

Dave Reynolds: We already have invisible extensions surely, if you add predicates existing rule sets potentially break. ←

14:49:40 <StellaMitchell> Axel: all the current dialects support all the datatypes specified in DTB

Axel Polleres: all the current dialects support all the datatypes specified in DTB ←

14:50:02 <josb> if you add predicates, you change the syntax, so the extension is not invisible

Jos de Bruijn: if you add predicates, you change the syntax, so the extension is not invisible ←

14:50:24 <DaveReynolds> No

Dave Reynolds: No ←

14:50:37 <StellaMitchell> Michael: the point of the isLiteralOfType predicate was to allow for extensibility

Michael Kifer: the point of the isLiteralOfType predicate was to allow for extensibility ←

14:50:58 <StellaMitchell> Axel: So people who exchange rules need to negotiate ahead of time what the datatypes are

Axel Polleres: So people who exchange rules need to negotiate ahead of time what the datatypes are ←

14:52:16 <StellaMitchell> Dave:  some iris are diallowed, eg.external functions

Dave Reynolds: some iris are diallowed, eg.external functions ←

14:52:44 <AxelPolleres> That is why we have External schemata.

Axel Polleres: That is why we have External schemata. ←

14:52:57 <StellaMitchell> Axel: no, we don't disallow any. There is a special syntax to indicate external functions

Axel Polleres: no, we don't disallow any. There is a special syntax to indicate external functions ←

14:53:04 <ChrisW> rrsagent, make logs public

Christopher Welty: rrsagent, make logs public ←

14:53:22 <ChrisW> TOPIC: IRIs for datatypes (etc)

1. IRIs for datatypes (etc)

14:53:25 <StellaMitchell> Sandro: But in BLD each IRI can only be used in one context

Sandro Hawke: But in BLD each IRI can only be used in one context ←

14:55:22 <sandro> DaveReynolds, is today's speaker phone better or worse than yesterday's?     Shall I switch back to yesterday's?

Sandro Hawke: DaveReynolds, is today's speaker phone better or worse than yesterday's? Shall I switch back to yesterday's? ←

14:55:29 <StellaMitchell> Michael: personally, I don't care whether we keep the restriction that an IRI can only occur in one context, and I also dn't care if we keep the restriction between functions and individuals

Michael Kifer: personally, I don't care whether we keep the restriction that an IRI can only occur in one context, and I also dn't care if we keep the restriction between functions and individuals ←

14:56:27 <StellaMitchell> Michael: Is there something in the Charter about supporting the merging of rulesets?

Michael Kifer: Is there something in the Charter about supporting the merging of rulesets? ←

14:57:44 <StellaMitchell> Sandro: say an extension defines complex numbers, you will get different entailments from a dialect that doesn't define them

Sandro Hawke: say an extension defines complex numbers, you will get different entailments from a dialect that doesn't define them ←

14:59:34 <sandro> if there's an extension that includes foo:compexNumber as a new subtype of owl:real, in instance document the predicate  isLiteralOfType("12i+4"^^foo:complexNumber, owl:real) will be false in the subdialect and true in the superdialect.

Sandro Hawke: if there's an extension that includes foo:compexNumber as a new subtype of owl:real, in instance document the predicate isLiteralOfType("12i+4"^^foo:complexNumber, owl:real) will be false in the subdialect and true in the superdialect. ←

14:59:57 <AxelPolleres> escape-scenario suggestion...If it was only for the OWLRL translation, we can define isliteralOftype just in terms of the per-type-guards.

Axel Polleres: escape-scenario suggestion...If it was only for the OWLRL translation, we can define isliteralOftype just in terms of the per-type-guards. ←

15:00:50 <AxelPolleres> ... so that one could be fixed easily, even if we fall back to per-dt-gurards, right?

Axel Polleres: ... so that one could be fixed easily, even if we fall back to per-dt-gurards, right? ←

15:01:16 <DaveReynolds> That case would be rejected in strict mode anyway, so it is not an invisible extension, it is visible.

Dave Reynolds: That case would be rejected in strict mode anyway, so it is not an invisible extension, it is visible. ←

15:01:27 <StellaMitchell> Chrisw: isLiteralOfType allows you to create invisible extensions

Christopher Welty: isLiteralOfType allows you to create invisible extensions ←

15:01:38 <StellaMitchell> Axel: We had 2 reasons for adding this predicate:

Axel Polleres: We had 2 reasons for adding this predicate: ←

15:01:59 <StellaMitchell> ...1. OWL-RL exercise, made the ruleset shorter

...1. OWL-RL exercise, made the ruleset shorter ←

15:02:05 <josb> the problem is rather isLiteralOfType("1"^^xs:int, foo:complexNumber)

Jos de Bruijn: the problem is rather isLiteralOfType("1"^^xs:int, foo:complexNumber) ←

15:02:32 <josb> in strict BLD it is false (or undefined), but in some extension that supports foo:complexNumber it is true

Jos de Bruijn: in strict BLD it is false (or undefined), but in some extension that supports foo:complexNumber it is true ←

15:02:56 <AxelPolleres> isliteraloftype (?X, xs:integer) :- isInteger(?X).

Axel Polleres: isliteraloftype (?X, xs:integer) :- isInteger(?X). ←

15:04:02 <StellaMitchell> Jos: could use individual guard predicates as well, for the OWL-RL

Jos de Bruijn: could use individual guard predicates as well, for the OWL-RL ←

15:04:30 <sandro> (Right, Dave, my example is not really a case of an invisible extension)

Sandro Hawke: (Right, Dave, my example is not really a case of an invisible extension) ←

15:04:54 <StellaMitchell> Dave: I'm not concerned with invisible extensions in this context; the point of this predicate was to allow people to extend dialects with new datatypes

Dave Reynolds: I'm not concerned with invisible extensions in this context; the point of this predicate was to allow people to extend dialects with new datatypes ←

15:05:50 <StellaMitchell> ... not having it is not a fundamental problem for the OWLRL ruleset

... not having it is not a fundamental problem for the OWLRL ruleset ←

15:06:29 <StellaMitchell> Jos: my understanding that the invisible extension discussion was about the datatypes

Jos de Bruijn: my understanding that the invisible extension discussion was about the datatypes ←

15:08:12 <StellaMitchell> Chrisw: the spirit of "no invisible extensions" was to allow for interoperability between dialects we current have and future ones

Christopher Welty: the spirit of "no invisible extensions" was to allow for interoperability between dialects we current have and future ones ←

15:09:18 <StellaMitchell> Michael:  Strict BLD should disallow new symbol spaces, because that would allow invisible extensions

Michael Kifer: Strict BLD should disallow new symbol spaces, because that would allow invisible extensions ←

15:09:29 <sandro> sandro: Yeah, that makes sense....

Sandro Hawke: Yeah, that makes sense.... [ Scribe Assist by Sandro Hawke ] ←

15:09:39 <StellaMitchell> ...we didn't say it's illegal to write new symbol spaces in BLD

...we didn't say it's illegal to write new symbol spaces in BLD ←

15:09:48 <sandro> sandro: We didn't realize symbol spaces could be added by users....

Sandro Hawke: We didn't realize symbol spaces could be added by users.... [ Scribe Assist by Sandro Hawke ] ←

15:10:05 <StellaMitchell> ...but we should now all that restriction for string conformance

...but we should now all that restriction for string conformance ←

15:10:15 <StellaMitchell> s/all/add/

s/all/add/ ←

15:10:23 <StellaMitchell> s/string/strict/

s/string/strict/ ←

15:11:28 <StellaMitchell> Chrisw:  what are people's opinions:

Christopher Welty: what are people's opinions: ←

15:11:50 <StellaMitchell> s/opinions/opinions on isLiteralOfType/

s/opinions/opinions on isLiteralOfType/ ←

15:11:56 <StellaMitchell> Jos: get  rid of it

Jos de Bruijn: get rid of it ←

15:12:00 <StellaMitchell> Dave: prefer to keep it

Dave Reynolds: prefer to keep it ←

15:12:02 <josb> in strict BLD it is false (or undefined), but in some extension that supports foo:complexNumber it is true

Jos de Bruijn: in strict BLD it is false (or undefined), but in some extension that supports foo:complexNumber it is true ←

15:12:04 <josb> the problem is rather isLiteralOfType("1"^^xs:int, foo:complexNumber)

Jos de Bruijn: the problem is rather isLiteralOfType("1"^^xs:int, foo:complexNumber) ←

15:12:15 <StellaMitchell> Sandro:  not fully understanding all the implications

Sandro Hawke: not fully understanding all the implications ←

15:12:25 <StellaMitchell> Axel: I prefer to keep it but see the problems

Axel Polleres: I prefer to keep it but see the problems ←

15:12:26 <MichaelKifer> p(?x) :- q(?x), isLiteralOfType("1"^^int, ?x)

Michael Kifer: p(?x) :- q(?x), isLiteralOfType("1"^^int, ?x) ←

15:13:10 <StellaMitchell> Michael:  for above example, some dialects might give an error

Michael Kifer: for above example, some dialects might give an error ←

15:13:12 <DaveReynolds> My preference order is (a) keep isLiteralOfType accepting it is allows invisible extensions, (b) keep it but with fixed set of datatypes, (c) revert to separate guards. I won't object to the latter.

Dave Reynolds: My preference order is (a) keep isLiteralOfType accepting it is allows invisible extensions, (b) keep it but with fixed set of datatypes, (c) revert to separate guards. I won't object to the latter. ←

15:13:46 <StellaMitchell> Jos:  a dialect could return false for any datatype that it doesn't recognize

Jos de Bruijn: a dialect could return false for any datatype that it doesn't recognize ←

15:14:05 <AxelPolleres> per-document-tags for supported DTs instead of supported DTs per dialect?

Axel Polleres: per-document-tags for supported DTs instead of supported DTs per dialect? ←

15:15:30 <StellaMitchell> Michael: I think this predicate is more trouble than it's worth

Michael Kifer: I think this predicate is more trouble than it's worth ←

15:15:32 <sandro> sandro: It's not an invisible extension IF we say isLiteralOfType( ... , X )  where X is not a known datatype, is undefined/error.

Sandro Hawke: It's not an invisible extension IF we say isLiteralOfType( ... , X ) where X is not a known datatype, is undefined/error. [ Scribe Assist by Sandro Hawke ] ←

15:15:59 <StellaMitchell> Chrisw: Dave, do you mean to have this predicate work only for datatypes defined in DTB

Christopher Welty: Dave, do you mean to have this predicate work only for datatypes defined in DTB ←

15:16:01 <StellaMitchell> Dave: yes

Dave Reynolds: yes ←

15:16:17 <sandro> dave's option b :   isLiteralOfCoreType(...)

Sandro Hawke: dave's option b : isLiteralOfCoreType(...) ←

15:16:23 <StellaMitchell> Chrisw: so Michael's example would be false for all other datatypes?

Christopher Welty: so Michael's example would be false for all other datatypes? ←

15:16:25 <StellaMitchell> Dave: yes

Dave Reynolds: yes ←

15:18:29 <AxelPolleres> isLiteralOfType(Lit,Type,ListOfDatatytpes)

Axel Polleres: isLiteralOfType(Lit,Type,ListOfDatatytpes) ←

15:18:53 <StellaMitchell> Chrisw: each dialect in addition to adding new types, has to define it's own isLiteralOfType, or add individual types

Christopher Welty: each dialect in addition to adding new types, has to define it's own isLiteralOfType, or add individual types ←

15:19:30 <StellaMitchell> Michael: so the original benefit of this predicate is taken away

Michael Kifer: so the original benefit of this predicate is taken away ←

15:21:16 <StellaMitchell> Axel: another option in addition to Dave's three above

Axel Polleres: another option in addition to Dave's three above ←

15:26:09 <StellaMitchell> Jos: a and b leave us with the problem of how to identify datatypes

Jos de Bruijn: a and b leave us with the problem of how to identify datatypes ←

15:26:49 <sandro> sandro: The user can implement B, given C.   (for some versions of datatype identifiers in B).     With A or B we have to decide if the second arg is rif:iri or xs:anyURI.

Sandro Hawke: The user can implement B, given C. (for some versions of datatype identifiers in B). With A or B we have to decide if the second arg is rif:iri or xs:anyURI. [ Scribe Assist by Sandro Hawke ] ←

15:27:05 <sandro> sandro: with rif:iri you don't know un-equality....

Sandro Hawke: with rif:iri you don't know un-equality.... [ Scribe Assist by Sandro Hawke ] ←

15:27:31 <StellaMitchell> Chrisw: Dave, is we go with a or b, do you care how datatypes are identified?

Christopher Welty: Dave, is we go with a or b, do you care how datatypes are identified? ←

15:28:34 <StellaMitchell> Dave: prefer string, but Jos's proposal is ok with me

Dave Reynolds: prefer string, but Jos's proposal is ok with me ←

15:29:53 <sandro> a1 ==  isLiteralOfTyle(...., foo:bar)  is FALSE                    a2 == isLiteralOfType(...., foo:bar) is unknown/error, but not very useful.

Sandro Hawke: a1 == isLiteralOfTyle(...., foo:bar) is FALSE a2 == isLiteralOfType(...., foo:bar) is unknown/error, but not very useful. ←

15:30:10 <sandro> s/unknown/undefined/

Sandro Hawke: s/unknown/undefined/ ←

15:30:20 <josb> p(?x) :- isLiteralOfType("1"^^int, ?x)

Jos de Bruijn: p(?x) :- isLiteralOfType("1"^^int, ?x) ←

15:31:08 <StellaMitchell> Chrisw: if we give undefined for unknown datatype, then the predicate is not so useful because cannot be used to extract datatypes

Christopher Welty: if we give undefined for unknown datatype, then the predicate is not so useful because cannot be used to extract datatypes ←

15:31:08 <sandro> a2 is extension-safe, but you can't write useful rules maybe....?

Sandro Hawke: a2 is extension-safe, but you can't write useful rules maybe....? ←

15:31:09 <josb> p("a") :- isLiteralOfType("1"^^int, "a")

Jos de Bruijn: p("a") :- isLiteralOfType("1"^^int, "a") ←

15:32:49 <sandro> sandro: Dave, you just need to trap the exception.

Sandro Hawke: Dave, you just need to trap the exception. [ Scribe Assist by Sandro Hawke ] ←

15:32:58 <StellaMitchell> Jos: for unknown datatype, returning false allows worse invisible extensions and returning undefined makes the predicate less useful

Jos de Bruijn: for unknown datatype, returning false allows worse invisible extensions and returning undefined makes the predicate less useful ←

15:35:01 <sandro> the problem with a1 is :   <josb> the problem is rather isLiteralOfType("1"^^xs:int, foo:complexNumber)

Sandro Hawke: the problem with a1 is : <josb> the problem is rather isLiteralOfType("1"^^xs:int, foo:complexNumber) ←

15:35:41 <StellaMitchell> Michael: a seems useless, b leaves problems of datatype identifiers

Michael Kifer: a seems useless, b leaves problems of datatype identifiers ←

15:36:00 <StellaMitchell> Jos: now prefer anyURI as datatype identifier

Jos de Bruijn: now prefer anyURI as datatype identifier ←

15:37:05 <StellaMitchell> Michael: prefix, import and base...inconistency in how we specify arguments to those

Michael Kifer: prefix, import and base...inconistency in how we specify arguments to those ←

15:37:30 <StellaMitchell> Jos: I prefer IRIs for all of those

Jos de Bruijn: I prefer IRIs for all of those ←

15:37:32 <sandro> this changes between true and false depending on whether the consumer implements foo:complexNumber, so it's an invisible extension --- fallback becomes theoretically impossible,

Sandro Hawke: this changes between true and false depending on whether the consumer implements foo:complexNumber, so it's an invisible extension --- fallback becomes theoretically impossible, ←

15:38:11 <StellaMitchell> Chrisw: everyone happy with IRIs for arguments of prefix, import and base

Christopher Welty: everyone happy with IRIs for arguments of prefix, import and base ←

15:38:18 <StellaMitchell> s/base/base?/

s/base/base?/ ←

15:38:23 <sandro> DaveReynolds: prefix, import, and base are strings which happen to be IRIs.

Dave Reynolds: prefix, import, and base are strings which happen to be IRIs. [ Scribe Assist by Sandro Hawke ] ←

15:39:11 <sandro> sandro: Use CURIEs for anyURI ?

Sandro Hawke: Use CURIEs for anyURI ? [ Scribe Assist by Sandro Hawke ] ←

15:39:13 <sandro> kifer: Yes.

Michael Kifer: Yes. [ Scribe Assist by Sandro Hawke ] ←

15:40:48 <DaveReynolds> You wouldn't use curies for prefix or base!

Dave Reynolds: You wouldn't use curies for prefix or base! ←

15:41:05 <StellaMitchell> Sandro: is anyURI a sybtype of string?   no it isn't.

Sandro Hawke: is anyURI a sybtype of string? no it isn't. ←

15:41:38 <DaveReynolds> Delimiter <...>

Dave Reynolds: Delimiter <...> ←

15:42:03 <StellaMitchell> Michael: rif:iris cause semantic problems, contants are correct for arguments to import, prefix and base

Michael Kifer: rif:iris cause semantic problems, contants are correct for arguments to import, prefix and base ←

15:42:25 <sandro> sandro: on solution - just use strings, instead of anyURI.

Sandro Hawke: on solution - just use strings, instead of anyURI. [ Scribe Assist by Sandro Hawke ] ←

15:42:30 <StellaMitchell> ...it  they are going to be constants, I prefer anyURI to string

...it they are going to be constants, I prefer anyURI to string ←

15:42:37 <StellaMitchell> ...but strings are ok

...but strings are ok ←

15:43:07 <StellaMitchell> Chrisw: won't we then have problems with curies?

Christopher Welty: won't we then have problems with curies? ←

15:44:52 <StellaMitchell> Dave: prefix, import and base arguments are just strings, and they are a completely different case from the syntax from isLiteralOfType

Dave Reynolds: prefix, import and base arguments are just strings, and they are a completely different case from the syntax from isLiteralOfType ←

15:45:57 <sandro> * Dave is proposing:

Sandro Hawke: * Dave is proposing: ←

15:45:57 <sandro> *    <foo> ==>  "foo"^^xs:anyURI   within Prefix, Base, Import

Sandro Hawke: * <foo> ==> "foo"^^xs:anyURI within Prefix, Base, Import ←

15:45:57 <sandro> *    <foo> ==>  "foo"^^rif:uri     everywhere else

Sandro Hawke: * <foo> ==> "foo"^^rif:uri everywhere else ←

15:46:41 <StellaMitchell> Dave: arguments to import, base and prefix are not constants in the language

Dave Reynolds: arguments to import, base and prefix are not constants in the language ←

15:47:04 <StellaMitchell> Sandro: we don't need any delimiter then

Sandro Hawke: we don't need any delimiter then ←

15:47:43 <StellaMitchell> ...(if we have spaces around parens)

...(if we have spaces around parens) ←

15:48:18 <StellaMitchell> Sandro: wants to use curies for base

Sandro Hawke: wants to use curies for base ←

15:48:38 <sandro> prefix this: <http:example.org/>

Sandro Hawke: prefix this: <http:example.org/> ←

15:48:41 <sandro> base this:

Sandro Hawke: base this: ←

15:48:56 <sandro> whatever.

Sandro Hawke: whatever. ←

15:50:29 <StellaMitchell> Chrisw: we need delimieters for import, prefix and base. I propose angle brackets because they connote web address

Christopher Welty: we need delimieters for import, prefix and base. I propose angle brackets because they connote web address ←

15:50:30 <sandro> PROPOSED:  < > as the delims in Prefix, Base, Import, and be careful not to confuse them with Consts.

PROPOSED: < > as the delims in Prefix, Base, Import, and be careful not to confuse them with Consts. ←

15:50:36 <StellaMitchell>  everyone: ok

everyone: ok ←

15:51:29 <sandro> Chrisw: Do we want a shortcut for xs:anyURIs.

Christopher Welty: Do we want a shortcut for xs:anyURIs. [ Scribe Assist by Sandro Hawke ] ←

15:51:52 <josb> nooooooooooooooooooooooooooooo

Jos de Bruijn: nooooooooooooooooooooooooooooo ←

15:52:11 <sandro> sandro: This makes option B goofy/nutty in the PS.

Sandro Hawke: This makes option B goofy/nutty in the PS. [ Scribe Assist by Sandro Hawke ] ←

15:52:47 <sandro> would like   isLiteralOfCoreType(?x, xsd:byte)

Sandro Hawke: would like isLiteralOfCoreType(?x, xsd:byte) ←

15:53:01 <sandro> would like   isLiteralOfCoreType(?x, "http:/....#byte"^^xs:anyURI)

Sandro Hawke: would like isLiteralOfCoreType(?x, "http:/....#byte"^^xs:anyURI) ←

15:53:15 <sandro> s/would like/have to do/

Sandro Hawke: s/would like/have to do/ ←

15:56:23 <josb> sandro, you propose isLiteralOfType("1"^^xs:int, xs:integer) is false?

Jos de Bruijn: sandro, you propose isLiteralOfType("1"^^xs:int, xs:integer) is false? ←

15:57:11 <josb> actually, you cannot distinguish between "1"^^xs:int and "1"^^integer

Jos de Bruijn: actually, you cannot distinguish between "1"^^xs:int and "1"^^integer ←

15:57:38 <josb> because they denote the same object in the domain (the number one)

Jos de Bruijn: because they denote the same object in the domain (the number one) ←

15:57:42 <sandro> Yes ....      (Axel explains) I'm looking for SPARQL's hasType which needs access to the Lexical Representaton, and we only have access to the value space....

Sandro Hawke: Yes .... (Axel explains) I'm looking for SPARQL's hasType which needs access to the Lexical Representaton, and we only have access to the value space.... ←

15:57:47 <josb> so, you cannot define isLiteralOfType to do this

Jos de Bruijn: so, you cannot define isLiteralOfType to do this ←

15:57:54 <AxelPolleres> sandro, you wouldn't get possibly the behaivour you expect....

Axel Polleres: sandro, you wouldn't get possibly the behaivour you expect.... ←

15:57:56 <ChrisW> action: michael to restrict use of symbol spaces in compliance section of BLD

ACTION: michael to restrict use of symbol spaces in compliance section of BLD ←

15:57:56 <trackbot> Sorry, amibiguous username (more than one match) - michael

Trackbot IRC Bot: Sorry, amibiguous username (more than one match) - michael ←

15:57:56 <trackbot> Try using a different identifier, such as family name or username (eg. msintek, mkifer, merdmann)

Trackbot IRC Bot: Try using a different identifier, such as family name or username (eg. msintek, mkifer, merdmann) ←

15:58:09 <ChrisW> action: kifer to restrict use of symbol spaces in compliance section of BLD

ACTION: kifer to restrict use of symbol spaces in compliance section of BLD ←

15:58:09 <trackbot> Created ACTION-750 - Restrict use of symbol spaces in compliance section of BLD [on Michael Kifer - due 2009-04-23].

Trackbot IRC Bot: Created ACTION-750 - Restrict use of symbol spaces in compliance section of BLD [on Michael Kifer - due 2009-04-23]. ←

15:58:33 <AxelPolleres> take isLiteralOfType("1"^^xs:unsignedInteger, ?X)

Axel Polleres: take isLiteralOfType("1"^^xs:unsignedInteger, ?X) ←

15:58:58 <AxelPolleres> ... and isLiteralOfType("1"^^xs:integer, ?X), they would ALWAYS need to have the same result.

Axel Polleres: ... and isLiteralOfType("1"^^xs:integer, ?X), they would ALWAYS need to have the same result. ←

15:59:25 <AxelPolleres> ... so your "pick-one" proposal wouldn't extract the datatype which was declared in the date necessary.

Axel Polleres: ... so your "pick-one" proposal wouldn't extract the datatype which was declared in the date necessary. ←

15:59:51 <AxelPolleres> ... I mean, in the lexical representation of the data.

Axel Polleres: ... I mean, in the lexical representation of the data. ←

16:01:20 <sandro> DaveReynolds, we'll reconvene in 90 minutes.

Sandro Hawke: DaveReynolds, we'll reconvene in 90 minutes. ←

16:02:22 <Zakim> -DaveReynolds

Zakim IRC Bot: -DaveReynolds ←

17:31:57 <ChrisW> hi dave

(No events recorded for 89 minutes)

Christopher Welty: hi dave ←

17:32:30 <ChrisW> just getting back into room

Christopher Welty: just getting back into room ←

17:32:42 <ChrisW> topic: PRD break-in

2. PRD break-in

17:33:04 <ChrisW> Scribe: MichaelKifer

(Scribe set to Michael Kifer)

17:34:02 <Zakim> + +45.44.1.aaaa

Zakim IRC Bot: + +45.44.1.aaaa ←

17:34:08 <csma> PROPOSED: add a semantically neutral construct to execute builtins in the conclusion (head or action part) in PRD rules, where the builtins MUST NOT affect the semantics of the rules. The syntax will mimick the syntax of External.

PROPOSED: add a semantically neutral construct to execute builtins in the conclusion (head or action part) in PRD rules, where the builtins MUST NOT affect the semantics of the rules. The syntax will mimick the syntax of External. ←

17:34:55 <MichaelKifer> csma: report on the PRD breakout

Christian de Sainte Marie: report on the PRD breakout ←

17:35:37 <sandro> Yes, DaveReynolds, we've started.

Sandro Hawke: Yes, DaveReynolds, we've started. ←

17:35:42 <sandro> zakim, who is on the phone

Sandro Hawke: zakim, who is on the phone ←

17:35:42 <Zakim> I don't understand 'who is on the phone', sandro

Zakim IRC Bot: I don't understand 'who is on the phone', sandro ←

17:35:44 <sandro> zakim, who is on the phone?

Sandro Hawke: zakim, who is on the phone? ←

17:35:44 <Zakim> On the phone I see MIT-G631, DaveReynolds

Zakim IRC Bot: On the phone I see MIT-G631, DaveReynolds ←

17:35:45 <Zakim> MIT-G631 has ChrisW, csma, Harold, MichaelKifer, AdrianP, SaidTabet, cke, johnhall, AxelPolleres, josb, GaryHallmark, StellaMitchell

Zakim IRC Bot: MIT-G631 has ChrisW, csma, Harold, MichaelKifer, AdrianP, SaidTabet, cke, johnhall, AxelPolleres, josb, GaryHallmark, StellaMitchell ←

17:35:54 <csma> PROPOSED: add Print as a builtin that can be Executed.

PROPOSED: add Print as a builtin that can be Executed. ←

17:36:56 <MichaelKifer> csma: semantically neutral builtin wrapper is one that cannot change the semantics of the rules.

Christian de Sainte Marie: semantically neutral builtin wrapper is one that cannot change the semantics of the rules. ←

17:38:12 <sandro> sandro: Agreed, print should not be in Core.

Sandro Hawke: Agreed, print should not be in Core. [ Scribe Assist by Sandro Hawke ] ←

17:38:51 <sandro> sandro: syntactically it's an external predicate.

Sandro Hawke: syntactically it's an external predicate. [ Scribe Assist by Sandro Hawke ] ←

17:41:43 <sandro> sandro: Is Print specified in PRD or DTB?   I think it should be in DTB -- but only for PRD.

Sandro Hawke: Is Print specified in PRD or DTB? I think it should be in DTB -- but only for PRD. [ Scribe Assist by Sandro Hawke ] ←

17:42:50 <csma> PROPOSED: add a semantically neutral construct to execute builtins in the conclusion (head or action part) in PRD rules, where the builtins MUST NOT affect the semantics of the rules. The syntax will mimick the syntax of External.

17:43:01 <cke> +1

Changhai Ke: +1 ←

17:43:04 <MichaelKifer> csma: Execute is a special wrapper for external actions. Won't use External for that in order to differentiate actions from predicate/functions.

Christian de Sainte Marie: Execute is a special wrapper for external actions. Won't use External for that in order to differentiate actions from predicate/functions. ←

17:43:05 <sandro> sandro: .... in the very-small section of PRD which lists the executable predcatices.

Sandro Hawke: .... in the very-small section of PRD which lists the executable predcatices. [ Scribe Assist by Sandro Hawke ] ←

17:43:09 <AdrianP> +1

17:43:22 <ChrisW> +1

17:43:22 <sandro> +1

17:43:27 <DaveReynolds> +1

17:43:27 <MichaelKifer> +1

+1 ←

17:43:29 <Harold> 1

Harold Boley: 1 ←

17:43:32 <GaryHallmark> +1

17:43:35 <josb> +1

17:43:37 <AxelPolleres> +1

17:43:44 <csma> RESOLVED: add a semantically neutral construct to execute builtins in the conclusion (head or action part) in PRD rules, where the builtins MUST NOT affect the semantics of the rules. The syntax will mimick the syntax of External.

RESOLVED: add a semantically neutral construct to execute builtins in the conclusion (head or action part) in PRD rules, where the builtins MUST NOT affect the semantics of the rules. The syntax will mimick the syntax of External. ←

17:44:05 <csma> PROPOSED: add Print as a builtin that can be Executed.

PROPOSED: add Print as a builtin that can be Executed. ←

17:46:32 <csma> PROPOSED: add Print as a builtin that can be Executed. The definition of that buitin goes in PRD.

PROPOSED: add Print as a builtin that can be Executed. The definition of that buitin goes in PRD. ←

17:46:59 <MichaelKifer> csma: whether to add the action-builtins to DTB or PRD?

Christian de Sainte Marie: whether to add the action-builtins to DTB or PRD? ←

17:47:40 <csma> PROPOSED: add Print as a builtin that can be Executed. The definition of that buitin goes in PRD. Closing ISSUE-62

PROPOSED: add Print as a builtin that can be Executed. The definition of that buitin goes in PRD. Closing ISSUE-62 ←

17:47:46 <MichaelKifer> the sentiment seems to be to keep this in PRD.

the sentiment seems to be to keep this in PRD. ←

17:48:23 <cke> +1

Changhai Ke: +1 ←

17:48:45 <sandro> sandro: So PRINT requires a new kind of test case, with a notion of an output stream.

Sandro Hawke: So PRINT requires a new kind of test case, with a notion of an output stream. [ Scribe Assist by Sandro Hawke ] ←

17:49:28 <cke> yes, we need to check that the output of an execution is such and such string

Changhai Ke: yes, we need to check that the output of an execution is such and such string ←

17:49:42 <Harold> Maybe add at least a 2nd executable right away to show generality.

Harold Boley: Maybe add at least a 2nd executable right away to show generality. ←

17:50:39 <csma> RESOLVED: add Print as a builtin that can be Executed. The definition of that buitin goes in PRD. Closing ISSUE-62.

RESOLVED: add Print as a builtin that can be Executed. The definition of that buitin goes in PRD. Closing ISSUE-62. ←

17:50:46 <ChrisW> +1

17:50:56 <Harold> +1

17:51:05 <DaveReynolds> +1

17:51:16 <MichaelKifer> +1

+1 ←

17:51:19 <AxelPolleres> +1

17:51:19 <sandro> +1

17:51:35 <csma> action: chrisw to close issue 62

ACTION: chrisw to close ISSUE-62 ←

17:51:35 <trackbot> Sorry, couldn't find user - chrisw

Trackbot IRC Bot: Sorry, couldn't find user - chrisw ←

17:51:50 <ChrisW> action: PRD editors to add eggsecute, modify, and print to prd

ACTION: PRD editors to add eggsecute, modify, and print to prd ←

17:51:50 <trackbot> Sorry, couldn't find user - PRD

Trackbot IRC Bot: Sorry, couldn't find user - PRD ←

17:52:03 <ChrisW> action: csma (PRD editors) to add eggsecute, modify, and print to prd

ACTION: csma (PRD editors) to add eggsecute, modify, and print to prd ←

17:52:03 <trackbot> Created ACTION-751 - (PRD editors) to add eggsecute, modify, and print to prd [on Christian de Sainte Marie - due 2009-04-23].

Trackbot IRC Bot: Created ACTION-751 - (PRD editors) to add eggsecute, modify, and print to prd [on Christian de Sainte Marie - due 2009-04-23]. ←

17:52:31 <sandro> sandro: what can you print?

Sandro Hawke: what can you print? [ Scribe Assist by Sandro Hawke ] ←

17:52:45 <csma> action: welty to close issue 62

ACTION: welty to close ISSUE-62 ←

17:52:45 <trackbot> Created ACTION-752 - Close issue 62 [on Christopher Welty - due 2009-04-23].

Trackbot IRC Bot: Created ACTION-752 - Close ISSUE-62 [on Christopher Welty - due 2009-04-23]. ←

17:53:09 <sandro> gary: anything that can be coerced to string -- which is any literal

Gary Hallmark: anything that can be coerced to string -- which is any literal [ Scribe Assist by Sandro Hawke ] ←

17:53:15 <csma> egg est cute

Christian de Sainte Marie: egg est cute ←

17:53:54 <ChrisW> TOPIC: datatype IRIs etc break-in

3. datatype IRIs etc break-in

17:54:22 <MichaelKifer> chrisw: report on the IRI identifier breakout

Christopher Welty: report on the IRI identifier breakout ←

17:54:58 <ChrisW> rrsagent, make minutes

Christopher Welty: rrsagent, make minutes ←

17:54:58 <RRSAgent> I have made the request to generate http://www.w3.org/2009/04/16-rif-minutes.html ChrisW

RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2009/04/16-rif-minutes.html ChrisW ←

17:57:56 <sandro> Looking at: http://www.w3.org/2005/rules/wg/meeting/2009-04-16#line0148

Sandro Hawke: Looking at: http://www.w3.org/2005/rules/wg/meeting/2009-04-16#line0148 ←

17:59:23 <sandro> isLiteralOfCoreType(...)

Sandro Hawke: isLiteralOfCoreType(...) ←

18:00:48 <sandro> gary: syntactic vinegar

Gary Hallmark: syntactic vinegar [ Scribe Assist by Sandro Hawke ] ←

18:02:24 <GaryHallmark> I like (c)

Gary Hallmark: I like (c) ←

18:06:54 <MichaelKifer> DaveR: does not see invisible extensions caused by isLiteralOfType as a serious problem

Dave Reynolds: does not see invisible extensions caused by isLiteralOfType as a serious problem ←

18:07:25 <sandro> It's not about using an IRI carelessly -- it's about using an IRI for a datatype that's not implemented in some dialect.

Sandro Hawke: It's not about using an IRI carelessly -- it's about using an IRI for a datatype that's not implemented in some dialect. ←

18:08:04 <sandro> (a situation that with option-A would give you the wrong answer, instead of a detectable situation where you know you're in the wrong dialect.)

Sandro Hawke: (a situation that with option-A would give you the wrong answer, instead of a detectable situation where you know you're in the wrong dialect.) ←

18:08:38 <sandro> (well, it would show up as a strictness violation, maybe.     I dunno.)

Sandro Hawke: (well, it would show up as a strictness violation, maybe. I dunno.) ←

18:08:46 <MichaelKifer> call for objections to option (c)...

call for objections to option (c)... ←

18:09:20 <sandro> PROPOSED: We'll get rid of the general guards and go back to positive and negative literal guards, one of each for each datatype.

PROPOSED: We'll get rid of the general guards and go back to positive and negative literal guards, one of each for each datatype. ←

18:09:36 <sandro> PROPOSED: We'll get rid of the general guards and go back to positive and negative literal guards, one of each for each datatype. (closing ISSUE-93 since it no longer matters)

PROPOSED: We'll get rid of the general guards and go back to positive and negative literal guards, one of each for each datatype. (closing ISSUE-93 since it no longer matters) ←

18:09:46 <AxelPolleres> currently we have as a naming convention for guards: pred:is<i>DATATYPE</i>, pred:isNot<i>DATATYPE</i>

Axel Polleres: currently we have as a naming convention for guards: pred:is<i>DATATYPE</i>, pred:isNot<i>DATATYPE</i> ←

18:09:50 <MichaelKifer> +1

+1 ←

18:09:53 <DaveReynolds> 0

Dave Reynolds: 0 ←

18:09:55 <Harold> +1

18:09:58 <sandro> +1

18:10:03 <AdrianP> 0

Adrian Paschke: 0 ←

18:10:03 <josb> +1

18:10:12 <ChrisW> +1

18:10:14 <GaryHallmark> +1

18:10:26 <AxelPolleres> +1

18:10:35 <ChrisW> DaveR and Adrian would have preferred to keep the isLiteralOfType guards

Christopher Welty: DaveR and Adrian would have preferred to keep the isLiteralOfType guards ←

18:10:48 <ChrisW> action: Chris to close issue-93

ACTION: Chris to close ISSUE-93 ←

18:10:48 <trackbot> Created ACTION-753 - Close issue-93 [on Christopher Welty - due 2009-04-23].

Trackbot IRC Bot: Created ACTION-753 - Close ISSUE-93 [on Christopher Welty - due 2009-04-23]. ←

18:10:51 <sandro> RESOLVED: We'll get rid of the general guards and go back to positive and negative literal guards, one of each for each datatype. (closing ISSUE-93 since it no longer matters)

RESOLVED: We'll get rid of the general guards and go back to positive and negative literal guards, one of each for each datatype. (closing ISSUE-93 since it no longer matters) ←

18:11:04 <GaryHallmark> naming? pred:is-literal-and-not-integer

Gary Hallmark: naming? pred:is-literal-and-not-integer ←

18:11:25 <sandro>  guard:int    nguard:int

Sandro Hawke: guard:int nguard:int ←

18:11:28 <MichaelKifer> axel: want to be the names of the guards to be the same as the data type name

Axel Polleres: want to be the names of the guards to be the same as the data type name ←

18:12:12 <AxelPolleres>  xs:integer(X, true^^boolean) , xs:integer(X, false^^boolean)

Axel Polleres: xs:integer(X, true^^boolean) , xs:integer(X, false^^boolean) ←

18:13:51 <sandro> the second arg is whether it's pos or neg.

Sandro Hawke: the second arg is whether it's pos or neg. ←

18:15:27 <sandro>  pred:isLiteralNotInteger(...)

Sandro Hawke: pred:isLiteralNotInteger(...) ←

18:15:56 <sandro>  pred:isLiteralNotInteger(...) and pred:isInteger(...)

Sandro Hawke: pred:isLiteralNotInteger(...) and pred:isInteger(...) ←

18:18:32 <sandro>  OPTION-1:    uppercase the first letter of the local part, and append to "isLiteralNot" and "is", ... in pred: OR some other namespace.

Sandro Hawke: OPTION-1: uppercase the first letter of the local part, and append to "isLiteralNot" and "is", ... in pred: OR some other namespace. ←

18:19:05 <AxelPolleres> http://www.w3.org/2005/rules/wiki/DTB#Guard_Predicates_for_Datatypes (current version)

Axel Polleres: http://www.w3.org/2005/rules/wiki/DTB#Guard_Predicates_for_Datatypes (current version) ←

18:19:14 <MichaelKifer>  pred:integer and pred:non-integer

pred:integer and pred:non-integer ←

18:19:30 <sandro>  OPTION-2:    take local part, append to "is-literal-not" and "is-\", ... in pred: OR some other namespace.

Sandro Hawke: OPTION-2: take local part, append to "is-literal-not" and "is-\", ... in pred: OR some other namespace. ←

18:19:36 <sandro>  OPTION-2:    take local part, append to "is-literal-not" and "is-", ... in pred: OR some other namespace.

Sandro Hawke: OPTION-2: take local part, append to "is-literal-not" and "is-", ... in pred: OR some other namespace. ←

18:20:07 <GaryHallmark>  pred:is-integer pred:is-literal-and-not-integer

Gary Hallmark: pred:is-integer pred:is-literal-and-not-integer ←

18:20:23 <josb> +1 OPTION-2

Jos de Bruijn: +1 OPTION-2 ←

18:20:37 <sandro> "non-"

Sandro Hawke: "non-" ←

18:20:54 <DaveReynolds> The literal predicates should be named by encoding in the whitespace language: http://compsoc.dur.ac.uk/whitespace/ :-)

Dave Reynolds: The literal predicates should be named by encoding in the whitespace language: http://compsoc.dur.ac.uk/whitespace/ :-) ←

18:23:55 <GaryHallmark>  pred:has-a-datatype-but-it-aint-intege

Gary Hallmark: pred:has-a-datatype-but-it-aint-intege ←

18:26:15 <DaveReynolds> If #4 (which I can't see) is Axel's one from above then I really don't like, it overloads casting in a confusing way.

Dave Reynolds: If #4 (which I can't see) is Axel's one from above then I really don't like, it overloads casting in a confusing way. ←

18:27:06 <GaryHallmark> dave, yes, #4 is Axel's

Gary Hallmark: dave, yes, #4 is Axel's ←

18:28:33 <sandro> OPTION-1

Sandro Hawke: OPTION-1 ←

18:28:41 <GaryHallmark> +1 for #2

Gary Hallmark: +1 for #2 ←

18:28:52 <AxelPolleres> 4) followed by 1)

Axel Polleres: 4) followed by 1) ←

18:28:55 <MichaelKifer> int non-int

int non-int ←

18:33:07 <sandro> RESOLVED: we'll use guards with names like pred:is-int and pred:is-literal-not-int   (but maybe some other word than "literal")

RESOLVED: we'll use guards with names like pred:is-int and pred:is-literal-not-int (but maybe some other word than "literal") ←

18:33:47 <ChrisW> action: axel to add guards back to DTB with naming conventions

ACTION: axel to add guards back to DTB with naming conventions ←

18:33:47 <trackbot> Created ACTION-754 - Add guards back to DTB with naming conventions [on Axel Polleres - due 2009-04-23].

Trackbot IRC Bot: Created ACTION-754 - Add guards back to DTB with naming conventions [on Axel Polleres - due 2009-04-23]. ←

18:33:52 <sandro> (from verbal discussion, using writing on note-pad.)

Sandro Hawke: (from verbal discussion, using writing on note-pad.) ←

18:34:38 <MichaelKifer> discussion of Prefix, Base, Import

discussion of Prefix, Base, Import ←

18:35:06 <MichaelKifer> proposal was to use IRI unicode strings delimited with <...>

proposal was to use IRI unicode strings delimited with <...> ←

18:35:30 <MichaelKifer> Base and Import cannot use curies

Base and Import cannot use curies ←

18:36:05 <MichaelKifer> Prefix also can't use curies, of course

Prefix also can't use curies, of course ←

18:36:24 <DaveReynolds> Base and prefix should not be part of the XML, there are only about the PS.

Dave Reynolds: Base and prefix should not be part of the XML, there are only about the PS. ←

18:36:56 <sandro> PROPOSED: Prefix, Base, and Import will treat their URIs as an anyURI, NOT a Const.   (in the XML).       In the PS it will look the same, using <...>, but not use CURIEs.

PROPOSED: Prefix, Base, and Import will treat their URIs as an anyURI, NOT a Const. (in the XML). In the PS it will look the same, using <...>, but not use CURIEs. ←

18:37:39 <josb> +1

18:37:40 <sandro> errr, Prefix and Base don't appear in the XML.

Sandro Hawke: errr, Prefix and Base don't appear in the XML. ←

18:38:21 <sandro> PROPOSED: In the XML syntax, the xml-schema type of the argument to import is an anyURI -- it's an a rif Const element.

PROPOSED: In the XML syntax, the xml-schema type of the argument to import is an anyURI -- it's an a rif Const element. ←

18:38:33 <sandro> PROPOSED: In the XML syntax, the xml-schema type of the argument to import is an anyURI -- it's NOT a rif Const element.

PROPOSED: In the XML syntax, the xml-schema type of the argument to import is an anyURI -- it's NOT a rif Const element. ←

18:38:40 <DaveReynolds> +1

18:38:43 <josb> +1

18:38:44 <sandro> +1

18:38:47 <AxelPolleres> +1

18:38:49 <ChrisW> +1

18:38:52 <AdrianP> +1

18:38:55 <csma> +1

Christian de Sainte Marie: +1 ←

18:39:13 <Harold> +1

18:40:54 <sandro> PROPOSED: In the XML syntax (for Core, BLD, PRD), the xml-schema type of both arguments to import is an anyURI -- it's NOT a rif Const element.

PROPOSED: In the XML syntax (for Core, BLD, PRD), the xml-schema type of both arguments to import is an anyURI -- it's NOT a rif Const element. ←

18:41:00 <josb> +1

18:41:05 <sandro> PROPOSED: 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).

PROPOSED: 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). ←

18:41:20 <DaveReynolds> +1

18:41:25 <ChrisW> +1

18:42:58 <sandro> csma: Maybe the second Arg should be from a fixed vocabulary.....?

Christian de Sainte Marie: Maybe the second Arg should be from a fixed vocabulary.....? [ Scribe Assist by Sandro Hawke ] ←

18:43:52 <sandro> Chrisw: We say you shouldn't process imports where you don't know the profile

Christopher Welty: We say you shouldn't process imports where you don't know the profile [ Scribe Assist by Sandro Hawke ] ←

18:43:54 <ChrisW> +1

18:44:01 <GaryHallmark> +

Gary Hallmark: + ←

18:44:01 <sandro> 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).

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). ←

18:44:06 <csma> ++

Christian de Sainte Marie: ++ ←

18:44:51 <sandro> PROPOSED: In RPS, we'll use <...> to delimit the IRI arguments to Import, Base, Prefix.

PROPOSED: In RPS, we'll use <...> to delimit the IRI arguments to Import, Base, Prefix. ←

18:45:20 <DaveReynolds> +1

18:45:24 <josb> +1

18:45:24 <AxelPolleres> +1

18:45:31 <csma> 0

Christian de Sainte Marie: 0 ←

18:45:32 <ChrisW> +1

18:45:34 <Harold> +1

18:45:34 <AdrianP> 0

Adrian Paschke: 0 ←

18:45:38 <sandro> PROPOSED: In RPS, 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.)

PROPOSED: In RPS, 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.) ←

18:45:53 <sandro> -0 it makes parsing more annoying

Sandro Hawke: -0 it makes parsing more annoying ←

18:46:05 <ChrisW> action: harold to update xml schema syntax for import

ACTION: harold to update xml schema syntax for import ←

18:46:05 <trackbot> Created ACTION-755 - Update xml schema syntax for import [on Harold Boley - due 2009-04-23].

Trackbot IRC Bot: Created ACTION-755 - Update xml schema syntax for import [on Harold Boley - due 2009-04-23]. ←

18:46:23 <GaryHallmark> 0

Gary Hallmark: 0 ←

18:46:28 <sandro> 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.)

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.) ←

18:46:55 <GaryHallmark>  reason: same as Sandro

Gary Hallmark: reason: same as Sandro ←

18:47:07 <ChrisW> action: harold to update ps to add <> to base, prefix and import

ACTION: harold to update ps to add <> to base, prefix and import ←

18:47:07 <trackbot> Created ACTION-756 - Update ps to add <> to base, prefix and import [on Harold Boley - due 2009-04-23].

Trackbot IRC Bot: Created ACTION-756 - Update ps to add <> to base, prefix and import [on Harold Boley - due 2009-04-23]. ←

18:47:10 <sandro> (But I don't have a better idea, so I go along with it.)

Sandro Hawke: (But I don't have a better idea, so I go along with it.) ←

18:47:22 <MichaelKifer> Restrict use of symbol spaces in compliance section of BLD

Restrict use of symbol spaces in compliance section of BLD ←

18:49:06 <csma> PROPOSED: Close ISSUE-07 (earlier resolution removed its object).

PROPOSED: Close ISSUE-07 (earlier resolution removed its object). ←

18:49:06 <sandro> kifer: If you add a datatype OR a symbol space, you're in a different dialect.

Michael Kifer: If you add a datatype OR a symbol space, you're in a different dialect. [ Scribe Assist by Sandro Hawke ] ←

18:49:16 <sandro> issue-97?

Sandro Hawke: ISSUE-97? ←

18:49:16 <trackbot> ISSUE-97 -- Shoudl Core safeness be restricted to Eiter-Schindlauer safeness -- OPEN

Trackbot IRC Bot: ISSUE-97 -- Shoudl Core safeness be restricted to Eiter-Schindlauer safeness -- OPEN ←

18:49:16 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/97

Trackbot IRC Bot: http://www.w3.org/2005/rules/wg/track/issues/97 ←

18:49:21 <csma> PROPOSED: Close ISSUE-97 (earlier resolution removed its object).

PROPOSED: Close ISSUE-97 (earlier resolution removed its object). ←

18:49:35 <DaveReynolds> +1

18:49:38 <ChrisW> +1

18:49:45 <GaryHallmark> +1

18:49:50 <sandro> +1

18:50:08 <Harold> +1

18:50:11 <MichaelKifer> +1

+1 ←

18:50:12 <AxelPolleres> +1

18:50:14 <josb> +1

Christian de Sainte Marie: ISSUE-96? ←

18:50:23 <johnhall> +1

John Hall: +1 ←

18:53:36 <csma> ISSUE-96?

18:53:36 <trackbot> ISSUE-96 -- General literal-< (etc.) predicate that covers < tests for all literals -- OPEN

Trackbot IRC Bot: ISSUE-96 -- General literal-< (etc.) predicate that covers < tests for all literals -- OPEN ←

18:53:36 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/96

Trackbot IRC Bot: http://www.w3.org/2005/rules/wg/track/issues/96 ←

18:53:44 <csma> At the 31-Mar-09 telecon, ISSUE-67 was discussed and Sandro observed that, for < to be a datatype-independent infix operator in the presentation syntax, there needs to be a "literal-<" predicate (as well as >, <=, >=) that subsumes the behavior of the datatype specific predicates.  For strings, this would wrap fn:compare, for numbers it would wrap numeric-<, and for incomparable types would...

Christian de Sainte Marie: At the 31-Mar-09 telecon, ISSUE-67 was discussed and Sandro observed that, for < to be a datatype-independent infix operator in the presentation syntax, there needs to be a "literal-<" predicate (as well as >, <=, >=) that subsumes the behavior of the datatype specific predicates. For strings, this would wrap fn:compare, for numbers it would wrap numeric-<, and for incomparable types would... ←

18:53:46 <csma> ...probably be undefined.

Christian de Sainte Marie: ...probably be undefined. ←

18:53:47 <csma> There was mild support for the notion at the telecon, provided someone was willing to do the work to specify it.

Christian de Sainte Marie: There was mild support for the notion at the telecon, provided someone was willing to do the work to specify it. ←

18:54:42 <ChrisW> PROPOSED: close ISSUE-96 without action

PROPOSED: close ISSUE-96 without action ←

18:54:46 <ChrisW> +1

18:54:53 <MichaelKifer> +1

+1 ←

18:54:56 <josb> +1

18:54:59 <AdrianP> +1

18:55:01 <DaveReynolds> +1

18:55:01 <ChrisW> RESOLVED: close ISSUE-96 without action

RESOLVED: close ISSUE-96 without action ←

18:55:07 <Harold> +1

18:55:09 <ChrisW> action: chris to close issue-96

ACTION: chris to close ISSUE-96 ←

18:55:09 <trackbot> Created ACTION-757 - Close issue-96 [on Christopher Welty - due 2009-04-23].

Trackbot IRC Bot: Created ACTION-757 - Close ISSUE-96 [on Christopher Welty - due 2009-04-23]. ←

18:55:17 <AxelPolleres> +1

Sandro Hawke: http://www.w3.org/2009/CommonScribe/panel/ ←

19:14:06 <sandro> http://www.w3.org/2009/CommonScribe/panel/

(No events recorded for 18 minutes)

19:21:54 <csma> Dave, we are about to reconvene

(No events recorded for 7 minutes)

Christian de Sainte Marie: Dave, we are about to reconvene ←

19:21:55 <sandro> http://www.w3.org/2005/rules/wiki/Lists

Sandro Hawke: http://www.w3.org/2005/rules/wiki/Lists ←

19:22:27 <ChrisW> ok

Christopher Welty: ok ←

19:23:04 <csma> http://www.w3.org/2005/rules/wiki/Lists#List_Builtins

Christian de Sainte Marie: http://www.w3.org/2005/rules/wiki/Lists#List_Builtins ←

19:24:31 <sandro> subtopic: #  empty(L)

3.1. # empty(L)

19:26:01 <sandro> csma: drop it because we don't need it.  keep the list short.

Christian de Sainte Marie: drop it because we don't need it. keep the list short. [ Scribe Assist by Sandro Hawke ] ←

19:26:14 <josb> empty(l) equiv l=Seq()

Jos de Bruijn: empty(l) equiv l=Seq() ←

19:26:58 <DaveReynolds> ?? Do we still have Seq() I thought we had builtins only

Dave Reynolds: ?? Do we still have Seq() I thought we had builtins only ←

19:27:15 <josb> we have ground lists

Jos de Bruijn: we have ground lists ←

19:27:20 <josb> and Seq() is a ground list

Jos de Bruijn: and Seq() is a ground list ←

19:27:41 <csma> empty(L) == count(L) = 0

Christian de Sainte Marie: empty(L) == count(L) = 0 ←

19:29:32 <DaveReynolds> It should be a literal rather than this special syntax surely

Dave Reynolds: It should be a literal rather than this special syntax surely ←

19:30:19 <DaveReynolds> +1 to be a builtin

Dave Reynolds: +1 to be a builtin ←

19:30:43 <Harold>  Predicates:

Harold Boley: Predicates: ←

19:30:56 <Harold> Scrap empty, exists, deep-equal

Harold Boley: Scrap empty, exists, deep-equal ←

19:31:03 <Harold>  Functions:

Harold Boley: Functions: ←

19:32:20 <Harold> s/Functions:/Change name of is-literal-not-list/

Harold Boley: s/Functions:/Change name of is-literal-not-list/ ←

19:34:04 <Harold> Rename contains

Harold Boley: Rename contains ←

19:36:30 <Harold> Want it: 7

Harold Boley: Want it: 7 ←

19:36:43 <DaveReynolds> contains is ok by me

Dave Reynolds: contains is ok by me ←

19:40:10 <Harold> contains( Seq( a Seq(1 2 3) b ) Seq(1 2 3) ) returns true

Harold Boley: contains( Seq( a Seq(1 2 3) b ) Seq(1 2 3) ) returns true ←

19:40:24 <Harold>  Functions:

Harold Boley: Functions: ←

19:41:52 <Harold> concatenate( Seq( a  b )  Seq(1 2 3) )  returns  Seq( a  b 1 2 3)

Harold Boley: concatenate( Seq( a b ) Seq(1 2 3) ) returns Seq( a b 1 2 3) ←

19:42:44 <Harold> concatenate is accepted.

Harold Boley: concatenate is accepted. ←

19:43:21 <DaveReynolds> index-of seems reasonable to me

Dave Reynolds: index-of seems reasonable to me ←

19:43:38 <csma> q?

19:44:01 <csma> ack axel

Christian de Sainte Marie: ack axel ←

19:49:32 <DaveReynolds> prefer to keep sublist/2 it's the nearest we have to tail

(No events recorded for 5 minutes)

Dave Reynolds: prefer to keep sublist/2 it's the nearest we have to tail ←

19:50:14 <csma> dave, would'nt you prefer to add tail?

Christian de Sainte Marie: dave, would'nt you prefer to add tail? ←

19:50:36 <DaveReynolds> Yes - head, tail and cons would be nice :-)

Dave Reynolds: Yes - head, tail and cons would be nice :-) ←

19:53:16 <DaveReynolds> inclined to remove avg - sum, just have reduce

Dave Reynolds: inclined to remove avg - sum, just have reduce ←

19:53:41 <DaveReynolds> q+

Dave Reynolds: q+ ←

19:54:21 <DaveReynolds> q-

Dave Reynolds: q- ←

19:56:47 <DaveReynolds> no to distinct-values, redundant

Dave Reynolds: no to distinct-values, redundant ←

19:57:47 <DaveReynolds> +1 to get

Dave Reynolds: +1 to get ←

19:58:20 <DaveReynolds> -1 to flatten

Dave Reynolds: -1 to flatten ←

19:58:45 <DaveReynolds> -1 to sort

Dave Reynolds: -1 to sort ←

20:05:58 <sandro> chrisw: lists are on anything.

(No events recorded for 7 minutes)

Christopher Welty: lists are on anything. [ Scribe Assist by Sandro Hawke ] ←

20:06:08 <AxelPolleres> Axel: What about defining lists only for literals (maybe nested), but not for arbitrary terms?

Axel Polleres: What about defining lists only for literals (maybe nested), but not for arbitrary terms? [ Scribe Assist by Axel Polleres ] ←

20:06:31 <AxelPolleres> ... would this restriction be reasonable, sufficient for the common use cases people have in mind.

Axel Polleres: ... would this restriction be reasonable, sufficient for the common use cases people have in mind. ←

20:06:35 <DaveReynolds> +0.5 for map

Dave Reynolds: +0.5 for map ←

20:08:13 <sandro> sandro: If you can't define your own functions, map is useless.

Sandro Hawke: If you can't define your own functions, map is useless. [ Scribe Assist by Sandro Hawke ] ←

20:08:28 <sandro> gary: No, it's good for casting.

Gary Hallmark: No, it's good for casting. [ Scribe Assist by Sandro Hawke ] ←

20:10:43 <sandro> chrisw: you can't implement a general map() in BLD, because you can't pass a function.  but you can implement a specific mapping function.

Christopher Welty: you can't implement a general map() in BLD, because you can't pass a function. but you can implement a specific mapping function. [ Scribe Assist by Sandro Hawke ] ←

20:11:12 <DaveReynolds> -1 to sort

Dave Reynolds: -1 to sort ←

20:11:17 <DaveReynolds> -1 to sort/2

Dave Reynolds: -1 to sort/2 ←

20:12:12 <DaveReynolds> -0.5 to delete

Dave Reynolds: -0.5 to delete ←

20:12:45 <DaveReynolds> -1 to compare

Dave Reynolds: -1 to compare ←

20:16:29 <csma> q?

Jos de Bruijn: http://www.w3.org/2005/rules/wiki/Lists#Semantics ←

20:17:05 <Harold> Chrisw: Can the remaining list preds/funcs be (easily) implemented?

Christopher Welty: Can the remaining list preds/funcs be (easily) implemented? [ Scribe Assist by Harold Boley ] ←

20:17:16 <josb> http://www.w3.org/2005/rules/wiki/Lists#Semantics

20:22:14 <sandro> jos: russel's paradox...?

Jos de Bruijn: russel's paradox...? [ Scribe Assist by Sandro Hawke ] ←

20:31:19 <ChrisW> Issue-99?

(No events recorded for 9 minutes)

Christopher Welty: ISSUE-99? ←

20:31:19 <trackbot> ISSUE-99 -- Drop restriction in core that there are no nested externals -- OPEN

Trackbot IRC Bot: ISSUE-99 -- Drop restriction in core that there are no nested externals -- OPEN ←

20:31:19 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/99

Trackbot IRC Bot: http://www.w3.org/2005/rules/wg/track/issues/99 ←

20:31:35 <ChrisW> Scribe: AdrianP

(Scribe set to Adrian Paschke)

20:34:00 <sandro> sandro: we agree functions in the head are just syntactic sugar,....

Sandro Hawke: we agree functions in the head are just syntactic sugar,.... [ Scribe Assist by Sandro Hawke ] ←

20:34:15 <AdrianP> Jos: well-formed formulas - cannot use functions

Jos de Bruijn: well-formed formulas - cannot use functions ←

20:34:17 <sandro> that is EXTERNALS.

Sandro Hawke: that is EXTERNALS. ←

20:35:55 <AdrianP> Jos: should be able to use external functions as terms

Jos de Bruijn: should be able to use external functions as terms ←

20:36:52 <sandro> PROPOSED: External functions are to be allowed in Core anywhere a Const is allowed.

PROPOSED: External functions are to be allowed in Core anywhere a Const is allowed. ←

20:37:52 <AdrianP> Harold: wanted to restrict them to the right hand side

Harold Boley: wanted to restrict them to the right hand side ←

20:37:54 <sandro> PROPOSED: External functions are to be allowed in Core anywhere TERM is.

PROPOSED: External functions are to be allowed in Core anywhere TERM is. ←

20:39:21 <sandro> PROPOSED: External functions are to be allowed in Core anywhere TERM is.     External functions are fine in predicate arguments in the head and body.

PROPOSED: External functions are to be allowed in Core anywhere TERM is. External functions are fine in predicate arguments in the head and body. ←

20:39:40 <josb> http://www.w3.org/2005/rules/wiki/Core#Formulas_of_RIF-Core

Jos de Bruijn: http://www.w3.org/2005/rules/wiki/Core#Formulas_of_RIF-Core ←

20:39:48 <sandro> http://www.w3.org/2005/rules/wiki/Core#Formulas_of_RIF-Core

Sandro Hawke: http://www.w3.org/2005/rules/wiki/Core#Formulas_of_RIF-Core ←

20:41:09 <AdrianP> Chrisw: add external functions to 2.3 first bullet

Christopher Welty: add external functions to 2.3 first bullet ←

20:41:48 <GaryHallmark> +1

20:42:49 <AdrianP> csma: do not want to allow external functions everywhere where you have TERM

Christian de Sainte Marie: do not want to allow external functions everywhere where you have TERM ←

20:43:20 <sandro> PROPOSED:    External functions are fine in predicate arguments in the head and body.     In general, External Functions are no more restricted in where they can occur in Core than BLD.

PROPOSED: External functions are fine in predicate arguments in the head and body. In general, External Functions are no more restricted in where they can occur in Core than BLD. ←

20:43:54 <sandro> +1

20:45:24 <sandro> PROPOSED:    External functions are fine in predicate arguments in the head and body.     In general, External Functions are no more restricted in where they can occur in Core than BLD.   They can be nested

PROPOSED: External functions are fine in predicate arguments in the head and body. In general, External Functions are no more restricted in where they can occur in Core than BLD. They can be nested ←

20:45:28 <GaryHallmark> +1

20:45:30 <sandro> +1

20:45:39 <josb> +1

20:45:42 <ChrisW> +1

20:45:43 <DaveReynolds> +1

20:45:45 <Harold> -0

Harold Boley: -0 ←

20:45:46 <AdrianP> +1

+1 ←

20:45:52 <AxelPolleres> +1

20:46:00 <sandro> RESOLVED: External functions are fine in predicate arguments in the head and body.     In general, External Functions are no more restricted in where they can occur in Core than BLD.   They can be nested

RESOLVED: External functions are fine in predicate arguments in the head and body. In general, External Functions are no more restricted in where they can occur in Core than BLD. They can be nested ←

20:46:01 <johnhall> +1

John Hall: +1 ←

20:46:03 <ChrisW> issue-100?

Christopher Welty: ISSUE-100? ←

20:46:03 <trackbot> ISSUE-100 -- Add and back into Core conclusion -- OPEN

Trackbot IRC Bot: ISSUE-100 -- Add and back into Core conclusion -- OPEN ←

20:46:03 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/100

Trackbot IRC Bot: http://www.w3.org/2005/rules/wg/track/issues/100 ←

20:46:14 <sandro> close issue-99

Sandro Hawke: close ISSUE-99 ←

20:46:14 <trackbot> ISSUE-99 Drop restriction in core that there are no nested externals closed

Trackbot IRC Bot: ISSUE-99 Drop restriction in core that there are no nested externals closed ←

20:46:52 <AdrianP> Jos: conjunctions in the head are allowed. BNF is not up-to-date

Jos de Bruijn: conjunctions in the head are allowed. BNF is not up-to-date ←

20:47:10 <ChrisW> dave - are you going to make the edit to CORE?

Christopher Welty: dave - are you going to make the edit to CORE? ←

20:47:11 <AdrianP> csma: resolved to allow conjunctions in the head for BLD

Christian de Sainte Marie: resolved to allow conjunctions in the head for BLD ←

20:47:29 <sandro> PROPOSED: Conjunction in the head is in Core.

PROPOSED: Conjunction in the head is in Core. ←

20:47:59 <sandro> PROPOSED: Conjunction in the head is in Core, closing ISSUE-100.    (this probably isn't a change; just being sure.)

PROPOSED: Conjunction in the head is in Core, closing ISSUE-100. (this probably isn't a change; just being sure.) ←

20:48:10 <sandro> +1

20:48:23 <ChrisW> action: harold to update CORE to implement issue-99 and issue 100

ACTION: harold to update CORE to implement ISSUE-99 and ISSUE-100 ←

20:48:23 <trackbot> Created ACTION-758 - Update CORE to implement issue-99 and issue 100 [on Harold Boley - due 2009-04-23].

Trackbot IRC Bot: Created ACTION-758 - Update CORE to implement ISSUE-99 and ISSUE-100 [on Harold Boley - due 2009-04-23]. ←

20:48:26 <DaveReynolds> +1

20:48:30 <ChrisW> +1

20:48:31 <josb> +1

20:48:37 <AxelPolleres> +1