RIF F2F13 -- 16 Apr 2009

<ChrisW> Scribe: cke

the subject is core safeness

<axel> looking at safety definition. How to extend to strongly safe ruleset.

<csma> dave, can you hear Axel?

<axel> we need disjonction in the body for this

<axel> if we limit lists to pure extracion operations, they will be safe

<chris> built-in for lists raise problems for Core

<csma> if the strong safeness is almost useless because of the lists,let's forget it

<axel> the defeinition can be changed into more elegant

<csma> we are talking about strong safeness only

<josb> RESOLVED: Core will be Eiter-Schindlauer-safe, but that restriction will be at risk (not putting in question simple safeness as defined in the current draft)

<josb> (March 10 telecon)

<jos> there will be only one safeness definition in core, and will be this one

<csma> nice to have this new definition today

<gary> need some examples to understand the scope/definition of each concept

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

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

<ChrisW> cke, use this syntax:

<ChrisW> axel: I would just make a note

<ChrisW> (use : not <>)

csma: if some engines won't acept the rulesets which are not strongly safe

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

csma: i do not understand the impact of the restriction. We need to understand the exact impacts

hb: in BLD, there are notions of conformance, strong and weak
... we could have a default conformance notion

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

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

<GaryHallmark> sense of room: many agreeing with Dave

chris: what does informative means? (if we put this as informative)

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

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

<AdrianP> +1

<GaryHallmark> +1

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

<DaveReynolds> +1

<stabet> +1

<AxelPolleres> +1

<Harold> +1

<ChrisW> ACTION: axel to draft E-S safety and make informative instead of at-risk [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action01]

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

csma: 10mn on list built-ins

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

sandro: we discussed the built-in in the wiki page

mf: do we add them to prd, or to core?

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

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

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

<DaveReynolds> Axel - exactly what I was on the queue to mention

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

<DaveReynolds> Could identify function by anyURI

<DaveReynolds> Horrid but legal

<stabet> L1, L2)

<sandro> who is scribe?

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

i'm scribe

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

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

<sandro> get(-1) == getLast, get(0) == getFirst

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

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

do we need sort?

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

15mn break

<sandro> reduce(function, iterable[, initializer])¶

<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> ault when the iterable is empty. If initializer is not given and iterable contains only one item, the first item is returned.

<ChrisW> dave?

<ChrisW> Scribe: StellaMitchell

<josb> isLiteralOfType

Jos: problem is how to identify datatypes, this is a result of the above predicate
... 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

<josb> isLiteralOfType("1"^^integer, xs:int)
..rif: iri is one possibility, but it is kludgy. Above example illustrates...

<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?
..rif: different results depending on whether or not you support the datatye

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

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

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

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

mk: join of two predicates?

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

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

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

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

<DaveReynolds> No

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

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

Dave: some iris are diallowed, eg.external functions

<AxelPolleres> That is why we have External schemata.

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

IRIs for datatypes (etc)

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

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

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
... Is there something in the Charter about supporting the merging of rulesets?

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

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

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

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

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

Chris: isLiteralOfType allows you to create invisible extensions

Axel: We had 2 reasons for adding this predicate:
... 1. OWL-RL exercise, made the ruleset shorter

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

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

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

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

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

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
... not having it is not a fundamental problem for the OWLRL ruleset

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

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

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

<sandro> sandro: Yeah, that makes sense....

Michael: we didn't say it's illegal to write new symbol spaces in BLD

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

Michael: but we should now add that restriction for strict conformance

Chris: what are people's opinions on isLiteralOfType:

Jos: get rid of it

Dave: prefer to keep it

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

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

Sandro: not fully understanding all the implications

Axel: I prefer to keep it but see the problems

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

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

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

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

<AxelPolleres> per-document-tags for supported DTs instead of supported DTs per dialect?

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

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

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

Dave: yes

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

Chris: so Michael's example would be false for all other datatypes?

Dave: yes

<AxelPolleres> isLiteralOfType(Lit,Type,ListOfDatatytpes)

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

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

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

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

<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> sandro: with rif:iri you don't know un-equality....

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

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

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

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

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

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

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

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

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

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

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

Jos: now prefer anyURI as datatype identifier

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

Jos: I prefer IRIs for all of those

<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,

Chris: everyone happy with IRIs for arguments of prefix, import and base?

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

<sandro> sandro: Use CURIEs for anyURI ?

<sandro> kifer: Yes.

<DaveReynolds> You wouldn't use curies for prefix or base!

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

<DaveReynolds> Delimiter <...>

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

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

Michael: it they are going to be constants, I prefer anyURI to string
... but strings are ok

Chris: won't we then have problems with curies?

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

<sandro> * Dave is proposing:

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

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

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

Sandro: we don't need any delimiter then
... (if we have spaces around parens)
... wants to use curies for base

<sandro> prefix this: <http:example.org/>

<sandro> base this:

<sandro> whatever.

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

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

everyone: ok

<sandro> Chris: Do we want a shortcut for xs:anyURIs.

<josb> nooooooooooooooooooooooooooooo

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

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

<sandro> have to do isLiteralOfCoreType(?x, "http:/....#byte"^^xs:anyURI)

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

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

<josb> because they denote the same object in the domain (the number one)

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

<josb> so, you cannot define isLiteralOfType to do this

<AxelPolleres> sandro, you wouldn't get possibly the behaivour you expect....

<ChrisW> ACTION: michael to restrict use of symbol spaces in compliance section of BLD [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action02]

<trackbot> Sorry, amibiguous username (more than one match) - michael

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

<ChrisW> ACTION: kifer to restrict use of symbol spaces in compliance section of BLD [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action03]

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

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

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

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

<AxelPolleres> ... I mean, in the lexical representation of the data.

<sandro> DaveReynolds, we'll reconvene in 90 minutes.

<ChrisW> hi dave

<ChrisW> just getting back into room

PRD break-in

<ChrisW> Scribe: MichaelKifer

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

csma: report on the PRD breakout

<sandro> Yes, DaveReynolds, we've started.

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

csma: semantically neutral builtin wrapper is one that cannot change the semantics of the rules.

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

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

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

<cke> +1

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

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

<AdrianP> +1

<ChrisW> +1

<sandro> +1

<DaveReynolds> +1

<Harold> 1

<GaryHallmark> +1

<josb> +1

<AxelPolleres> +1

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

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

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

csma: whether to add the action-builtins to DTB or PRD?

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

the sentiment seems to be to keep this in PRD.

<cke> +1

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

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

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

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

<ChrisW> +1

<Harold> +1

<DaveReynolds> +1

<AxelPolleres> +1

<sandro> +1

<csma> ACTION: chrisw to close issue 62 [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action04]

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

<ChrisW> ACTION: PRD editors to add eggsecute, modify, and print to prd [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action05]

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

<ChrisW> ACTION: csma (PRD editors) to add eggsecute, modify, and print to prd [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action06]

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

<sandro> sandro: what can you print?

<csma> ACTION: welty to close issue 62 [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action07]

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

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

<csma> egg est cute

datatype IRIs etc break-in

chris: report on the IRI identifier breakout

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

<sandro> isLiteralOfCoreType(...)

<sandro> gary: syntactic vinegar

<GaryHallmark> I like (c)

DaveR: does not see invisible extensions caused by isLiteralOfType as a serious problem

<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> (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> (well, it would show up as a strictness violation, maybe. I dunno.)

call for objections to option (c)...

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

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

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

<DaveReynolds> 0

<Harold> +1

<sandro> +1

<AdrianP> 0

<josb> +1

<ChrisW> +1

<GaryHallmark> +1

<AxelPolleres> +1

<ChrisW> DaveR and Adrian would have preferred to keep the isLiteralOfType guards

<ChrisW> ACTION: Chris to close issue-93 [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action08]

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

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

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

<sandro> guard:int nguard:int

axel: want to be the names of the guards to be the same as the data type name

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

<sandro> the second arg is whether it's pos or neg.

<sandro> pred:isLiteralNotInteger(...)

<sandro> pred:isLiteralNotInteger(...) and pred:isInteger(...)

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

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

pred: integer and pred:non-integer

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

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

<GaryHallmark> pred:is-integer pred:is-literal-and-not-integer

<josb> +1 OPTION-2

<sandro> "non-"

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

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

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

<GaryHallmark> dave, yes, #4 is Axel's

<sandro> OPTION-1

<GaryHallmark> +1 for #2

<AxelPolleres> 4) followed by 1)

int non-int

<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")

<ChrisW> ACTION: axel to add guards back to DTB with naming conventions [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action09]

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

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

discussion of Prefix, Base, Import

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

Base and Import cannot use curies

Prefix also can't use curies, of course

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

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

<josb> +1

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

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

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

<DaveReynolds> +1

<josb> +1

<sandro> +1

<AxelPolleres> +1

<ChrisW> +1

<AdrianP> +1

<csma> +1

<Harold> +1

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

<josb> +1

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

<DaveReynolds> +1

<ChrisW> +1

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

<sandro> Chris: We say you shouldn't process imports where you don't know the profile

<ChrisW> +1

<GaryHallmark> +

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

<csma> ++

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

<DaveReynolds> +1

<josb> +1

<AxelPolleres> +1

<csma> 0

<ChrisW> +1

<Harold> +1

<AdrianP> 0

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

<sandro> -0 it makes parsing more annoying

<ChrisW> ACTION: harold to update xml schema syntax for import [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action10]

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

<GaryHallmark> 0

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

<GaryHallmark> reason: same as Sandro

<ChrisW> ACTION: harold to update ps to add <> to base, prefix and import [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action11]

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

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

Restrict use of symbol spaces in compliance section of BLD

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

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

<sandro> issue-97?

<trackbot> ISSUE-97 -- Shoudl Core safeness be restricted to Eiter-Schindlauer safeness -- OPEN

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

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

<DaveReynolds> +1

<ChrisW> +1

<GaryHallmark> +1

<sandro> +1

<Harold> +1

<AxelPolleres> +1

<josb> +1

<johnhall> +1

<csma> ISSUE-96?

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

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

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

<csma> ...probably be undefined.

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

<ChrisW> PROPOSED: close ISSUE-96 without action

<ChrisW> +1

<josb> +1

<AdrianP> +1

<DaveReynolds> +1

<ChrisW> RESOLVED: close ISSUE-96 without action

<Harold> +1

<ChrisW> ACTION: chris to close issue-96 [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action12]

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

<AxelPolleres> +1

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

<csma> Dave, we are about to reconvene

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

<ChrisW> ok

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

<sandro> subtopic: # empty(L)

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

<josb> empty(l) equiv l=Seq()

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

<josb> we have ground lists

<josb> and Seq() is a ground list

<csma> empty(L) == count(L) = 0

<DaveReynolds> It should be a literal rather than this special syntax surely

<DaveReynolds> +1 to be a builtin

<Harold> Predicates:

<Harold> Scrap empty, exists, deep-equal

<Harold> Change name of is-literal-not-list

<Harold> Rename contains

<Harold> Want it: 7

<DaveReynolds> contains is ok by me

<Harold> contains( Seq( a Seq(1 2 3) b ) Seq(1 2 3) ) returns true

<Harold> Functions:

<Harold> concatenate( Seq( a b ) Seq(1 2 3) ) returns Seq( a b 1 2 3)

<Harold> concatenate is accepted.

<DaveReynolds> index-of seems reasonable to me

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

<csma> dave, would'nt you prefer to add tail?

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

<DaveReynolds> inclined to remove avg - sum, just have reduce

<DaveReynolds> no to distinct-values, redundant

<DaveReynolds> +1 to get

<DaveReynolds> -1 to flatten

<DaveReynolds> -1 to sort

<sandro> chris: lists are on anything.

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

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

<DaveReynolds> +0.5 for map

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

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

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

<DaveReynolds> -1 to sort

<DaveReynolds> -1 to sort/2

<DaveReynolds> -0.5 to delete

<DaveReynolds> -1 to compare

<Harold> Chris: Can the remaining list preds/funcs be (easily) implemented?

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

<sandro> jos: russel's paradox...?

<ChrisW> Issue-99?

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

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

<ChrisW> Scribe: AdrianP

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

Jos: well-formed formulas - cannot use functions

<sandro> that is EXTERNALS.

Jos: should be able to use external functions as terms

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

Harold: wanted to restrict them to the right hand side

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

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

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

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

Chris: add external functions to 2.3 first bullet

<GaryHallmark> +1

csma: do not want to allow external functions everywhere where you have TERM

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

<sandro> +1

<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

<GaryHallmark> +1

<sandro> +1

<josb> +1

<ChrisW> +1

<DaveReynolds> +1

<Harold> -0

<AxelPolleres> +1

<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

<johnhall> +1

<ChrisW> issue-100?

<trackbot> ISSUE-100 -- Add and back into Core conclusion -- OPEN

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

<sandro> close issue-99

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

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

<ChrisW> dave - are you going to make the edit to CORE?

cmsa: resolved to allow conjunctions in the head for BLD

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

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

<sandro> +1

<ChrisW> ACTION: harold to update CORE to implement issue-99 and issue 100 [recorded in http://www.w3.org/2009/04/16-rif-minutes.html#action13]

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

<DaveReynolds> +1

<ChrisW> +1

<josb> +1

<AxelPolleres> +1

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

<sandro> close issue-100

<trackbot> ISSUE-100 Add and back into Core conclusion closed

next topic: lists

michael: how to define count for lists

http://www.w3.org/2005/rules/wiki/Lists

<DaveReynolds> It's had to follow the discussion without a screen so I'll sign off.

<DaveReynolds> Have a good evening.

<sandro> Do we allow: List(1, external(numeric-add(1, ?x)), 3)

<sandro> Jos says No.

<sandro> Axel says if they do, in core, we might as well have function terms in Core.

<sandro> Sandro says: you can emulate it with insert-before

<Harold> ?x = List( | ?r) tests if ?x is a list.

<sandro> by taking out the negative guard, not-a-list (atomic) the user cannot implement flatten.

<sandro> everyone: uh, yeah.... oh well.

- DRAFT -

RIF F2F13

16 Apr 2009

Attendees

Contents

IRIs for datatypes (etc)

PRD break-in

datatype IRIs etc break-in

Summary of Action Items

Scribe.perl diagnostic output