Warning:
This wiki has been archived and is now read-only.
Chatlog 2009-04-16
From RIF
See original RRSAgent log and preview nicely formatted version.
Please justify/explain all edits to this page, in your "edit summary" text.
<sandro> PRESENT: adrian, axel, changhai, csma, welty, reynolds, gary, harold, john_hall, jos, kifer, sandro, said, stella
13:17:45 <RRSAgent> RRSAgent has joined #rif
13:17:45 <RRSAgent> logging to http://www.w3.org/2009/04/16-rif-irc
13:18:01 <GaryHallmark> GaryHallmark has joined #rif
13:18:19 <ChrisW> zakim, this is rif
13:18:19 <Zakim> ok, ChrisW; that matches SW_RIF(F2F)8:00AM
13:19:07 <ChrisW> Meeting: RIF F2F13
13:19:14 <cke> cke has joined #rif
13:19:19 <ChrisW> Chair: Chris Welty, Christian
13:19:40 <ChrisW> Agenda: http://www.w3.org/2005/rules/wiki/F2F13#Agenda
13:19:49 <ChrisW> Scribe: cke
13:20:01 <ChrisW> rrsagent, make minutes
13:20:01 <RRSAgent> I have made the request to generate http://www.w3.org/2009/04/16-rif-minutes.html ChrisW
13:20:25 <cke> the subject is core safeness
13:21:19 <ChrisW> zakim, MIT-G631 contains ChrisW, csma, Harold, MichaelKifer, AdrianP, SaidTabet, cke, johnhall, AxelPolleres, josb, GaryHallmark, StellaMitchell
13:21:19 <Zakim> +ChrisW, csma, Harold, MichaelKifer, AdrianP, SaidTabet, cke, johnhall, AxelPolleres, josb, GaryHallmark, StellaMitchell; got it
13:21:28 <cke> <axel> looking at safety definition. How to extend to strongly safe ruleset.
13:21:33 <csma> dave, can you hear Axel?
13:21:53 <cke> <axel> we need disjonction in the body for this
13:23:10 <cke> <axel> if we limit lists to pure extracion operations, they will be safe
13:23:46 <josb> q+
13:24:17 <stabet> stabet has joined #rif
13:24:18 <josb> q-
13:24:58 <cke> <chris> built-in for lists raise problems for Core
13:25:15 <DaveReynolds> q+
13:25:38 <stabet> stabet has joined #rif
13:26:10 <cke> <csma> if the strong safeness is almost useless because of the lists,let's forget it
13:28:37 <cke> <axel> the defeinition can be changed into more elegant
13:28:46 <MichaelKifer> MichaelKifer has joined #rif
13:29:29 <cke> <csma> we are talking about strong safeness only
13:30:05 <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)
13:31:02 <josb> (March 10 telecon)
13:31:15 <cke> <jos> there will be only one safeness definition in core, and will be this one
13:31:29 <cke> <csma> nice to have this new definition today
13:31:35 <ChrisW> q?
13:31:45 <ChrisW> ack DaveReynolds
13:34:50 <cke> <gary> need some examples to understand the scope/definition of each concept
13:41:04 <csma> q?
13:41:33 <josb> 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, ...
13:43:01 <ChrisW> cke, use this syntax:
13:43:09 <ChrisW> axel: I would just make a note
13:43:18 <ChrisW> (use : not <>)
13:43:27 <cke> csma: 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
13:46:46 <cke> csma: 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
13:48:37 <cke> hb: 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
13:49:52 <GaryHallmark> dave: strong safety should not be normative, just informative
13:50:11 <GaryHallmark> sense of room: many agreeing with Dave
13:50:17 <cke> chrisw: 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
13:51:39 <AxelPolleres> isn't "non-normative" the right word to be used in W3C docs?
13:52:14 <AdrianP> +1
13:52:15 <cke> +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
13:52:28 <DaveReynolds> +1
13:52:44 <stabet> +1
13:52:49 <AxelPolleres> +1
13:52:58 <Harold> +1
13:53:08 <ChrisW> 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].
13:53:59 <cke> csma: 10mn on list built-ins
13:54:15 <csma> http://www.w3.org/2005/rules/wiki/Lists#List_Builtins
13:56:48 <csma> q?
13:58:26 <sandro> sandro has joined #rif
13:58:34 <cke> sandro: we discussed the built-in in the wiki page
14:00:36 <sandro> RRSAgent, pointer?
14:00:36 <RRSAgent> 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?
14:03:48 <DaveReynolds> q+
14:04:05 <Harold> 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)?
14:06:45 <DaveReynolds> 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
14:09:23 <AxelPolleres> q+
14:09:32 <DaveReynolds> Could identify function by anyURI
14:09:44 <DaveReynolds> Horrid but legal
14:11:00 <stabet> L1, L2)
14:11:27 <sandro> who is scribe?
14:11:33 <stabet> sorry I meant to say: how about adding is-sublist?
14:11:47 <cke> i'm scribe
14:12:35 <cke> 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.
14:13:27 <sandro> 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.
14:15:48 <DaveReynolds> 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?
14:18:50 <josb> josb has joined #rif
14:21:53 <cke> there may be a solution to implement map/reduce. we can pass a code for a function
14:22:10 <cke> 15mn break
14:23:49 <sandro> 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
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.
14:39:07 <ChrisW> dave?
14:39:18 <ChrisW> zakim, who is on the phone?
14:39:18 <Zakim> 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
14:43:04 <MichaelKifer> MichaelKifer has joined #rif
14:43:07 <ChrisW> Scribe: StellaMitchell
14:43:38 <josb> isLiteralOfType
14:43:43 <StellaMitchell> Jos: 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
14:44:47 <josb> isLiteralOfType("1"^^integer, xs:int)
14:45:24 <StellaMitchell> ..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?
14:46:12 <StellaMitchell> ...different results depending on whether or not you support the datatye
14:46:50 <josb> p(?x) :- isLiteralOfType("1"^^int, ?x)
14:47:39 <StellaMitchell> Jos: 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.
14:48:08 <StellaMitchell> ...for some values, it will be unspecified according to DTB and good practice would be to raise an error
14:48:40 <GaryHallmark> GaryHallmark has joined #rif
14:48:54 <StellaMitchell> mk: join of two predicates?
14:48:58 <MichaelKifer> 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.
14:49:40 <StellaMitchell> Axel: 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
14:50:11 <johnhall> johnhall has joined #rif
14:50:24 <DaveReynolds> No
14:50:37 <StellaMitchell> Michael: the point of the isLiteralOfType predicate was to allow for extensibility
14:50:58 <csma> csma has joined #rif
14:50:58 <StellaMitchell> Axel: So people who exchange rules need to negotiate ahead of time what the datatypes are
14:52:10 <Harold> Harold has joined #rif
14:52:16 <StellaMitchell> Dave: some iris are diallowed, eg.external functions
14:52:44 <AxelPolleres> 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
14:53:04 <ChrisW> rrsagent, make logs public
14:53:22 <ChrisW> TOPIC: IRIs for datatypes (etc)
14:53:25 <StellaMitchell> Sandro: 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?
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
14:56:27 <StellaMitchell> Michael: 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
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.
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.
15:00:50 <AxelPolleres> ... 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.
15:01:27 <StellaMitchell> Chrisw: isLiteralOfType allows you to create invisible extensions
15:01:38 <StellaMitchell> Axel: We had 2 reasons for adding this predicate:
15:01:59 <StellaMitchell> ...1. OWL-RL exercise, made the ruleset shorter
15:02:05 <josb> 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
15:02:56 <AxelPolleres> isliteraloftype (?X, xs:integer) :- isInteger(?X).
15:04:02 <StellaMitchell> Jos: 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)
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
15:05:15 <MoZ> MoZ has joined #rif
15:05:50 <StellaMitchell> ... 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
15:08:06 <GaryHallmark> GaryHallmark has joined #rif
15:08:12 <StellaMitchell> Chrisw: 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
15:09:29 <sandro> sandro: Yeah, that makes sense....
15:09:39 <StellaMitchell> ...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....
15:10:05 <StellaMitchell> ...but we should now all that restriction for string conformance
15:10:15 <StellaMitchell> s/all/add/
15:10:23 <StellaMitchell> s/string/strict/
15:11:28 <StellaMitchell> Chrisw: what are people's opinions:
15:11:50 <StellaMitchell> s/opinions/opinions on isLiteralOfType/
15:11:56 <StellaMitchell> Jos: get rid of it
15:12:00 <StellaMitchell> Dave: 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
15:12:04 <josb> the problem is rather isLiteralOfType("1"^^xs:int, foo:complexNumber)
15:12:15 <StellaMitchell> Sandro: not fully understanding all the implications
15:12:25 <StellaMitchell> Axel: I prefer to keep it but see the problems
15:12:26 <MichaelKifer> p(?x) :- q(?x), isLiteralOfType("1"^^int, ?x)
15:13:10 <StellaMitchell> Michael: 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.
15:13:46 <StellaMitchell> Jos: 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?
15:15:30 <StellaMitchell> Michael: 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.
15:15:59 <StellaMitchell> Chrisw: Dave, do you mean to have this predicate work only for datatypes defined in DTB
15:16:01 <StellaMitchell> Dave: yes
15:16:17 <sandro> dave's option b : isLiteralOfCoreType(...)
15:16:23 <StellaMitchell> Chrisw: so Michael's example would be false for all other datatypes?
15:16:25 <StellaMitchell> Dave: yes
15:18:29 <AxelPolleres> 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
15:19:30 <StellaMitchell> Michael: so the original benefit of this predicate is taken away
15:21:16 <StellaMitchell> Axel: 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
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.
15:27:05 <sandro> sandro: with rif:iri you don't know un-equality....
15:27:31 <StellaMitchell> Chrisw: 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
15:29:53 <sandro> a1 == isLiteralOfTyle(...., foo:bar) is FALSE a2 == isLiteralOfType(...., foo:bar) is unknown/error, but not very useful.
15:30:10 <sandro> s/unknown/undefined/
15:30:20 <josb> 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
15:31:08 <sandro> a2 is extension-safe, but you can't write useful rules maybe....?
15:31:09 <josb> p("a") :- isLiteralOfType("1"^^int, "a")
15:32:49 <sandro> sandro: Dave, you just need to trap the exception.
15:32:58 <StellaMitchell> Jos: 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)
15:35:41 <StellaMitchell> Michael: a seems useless, b leaves problems of datatype identifiers
15:36:00 <StellaMitchell> Jos: now prefer anyURI as datatype identifier
15:37:05 <StellaMitchell> Michael: prefix, import and base...inconistency in how we specify arguments to those
15:37:30 <StellaMitchell> Jos: 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,
15:38:11 <StellaMitchell> Chrisw: everyone happy with IRIs for arguments of prefix, import and base
15:38:18 <StellaMitchell> s/base/base?/
15:38:23 <sandro> DaveReynolds: prefix, import, and base are strings which happen to be IRIs.
15:39:11 <sandro> sandro: Use CURIEs for anyURI ?
15:39:13 <sandro> kifer: Yes.
15:40:48 <DaveReynolds> You wouldn't use curies for prefix or base!
15:41:05 <StellaMitchell> Sandro: is anyURI a sybtype of string? no it isn't.
15:41:38 <DaveReynolds> Delimiter <...>
15:42:03 <StellaMitchell> Michael: 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.
15:42:30 <StellaMitchell> ...it they are going to be constants, I prefer anyURI to string
15:42:37 <StellaMitchell> ...but strings are ok
15:43:07 <StellaMitchell> Chrisw: 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
15:45:57 <sandro> * Dave is proposing:
15:45:57 <sandro> * <foo> ==> "foo"^^xs:anyURI within Prefix, Base, Import
15:45:57 <sandro> * <foo> ==> "foo"^^rif:uri everywhere else
15:46:41 <StellaMitchell> Dave: arguments to import, base and prefix are not constants in the language
15:47:04 <StellaMitchell> Sandro: we don't need any delimiter then
15:47:43 <StellaMitchell> ...(if we have spaces around parens)
15:48:18 <StellaMitchell> Sandro: wants to use curies for base
15:48:38 <sandro> prefix this: <http:example.org/>
15:48:41 <sandro> base this:
15:48:56 <sandro> whatever.
15:50:29 <StellaMitchell> Chrisw: 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.
15:50:36 <StellaMitchell> everyone: ok
15:51:29 <sandro> Chrisw: Do we want a shortcut for xs:anyURIs.
15:51:52 <josb> nooooooooooooooooooooooooooooo
15:52:11 <sandro> sandro: This makes option B goofy/nutty in the PS.
15:52:47 <sandro> would like isLiteralOfCoreType(?x, xsd:byte)
15:53:01 <sandro> would like isLiteralOfCoreType(?x, "http:/....#byte"^^xs:anyURI)
15:53:15 <sandro> s/would like/have to do/
15:56:23 <josb> 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
15:57:38 <josb> 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....
15:57:47 <josb> so, you cannot define isLiteralOfType to do this
15:57:54 <AxelPolleres> 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
15:57:56 <trackbot> 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)
15:58:09 <ChrisW> 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].
15:58:33 <AxelPolleres> 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.
15:59:25 <AxelPolleres> ... 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.
16:01:20 <sandro> DaveReynolds, we'll reconvene in 90 minutes.
16:02:22 <Zakim> -DaveReynolds
17:29:07 <josb> josb has joined #rif
17:30:24 <MichaelKifer> MichaelKifer has joined #rif
17:31:28 <ChrisW> ChrisW has joined #rif
17:31:30 <DaveReynolds> DaveReynolds has joined #rif
17:31:57 <ChrisW> hi dave
17:32:30 <ChrisW> just getting back into room
17:32:42 <ChrisW> topic: PRD break-in
17:32:50 <GaryHallmark> GaryHallmark has joined #rif
17:33:04 <ChrisW> Scribe: MichaelKifer
17:33:06 <csma> csma has joined #rif
17:33:53 <Harold> Harold has joined #rif
17:34:02 <Zakim> + +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.
17:34:12 <AdrianP> AdrianP has joined #rif
17:34:16 <cke> cke has joined #rif
17:34:45 <AxelPolleres> AxelPolleres has joined #rif
17:34:55 <MichaelKifer> csma: report on the PRD breakout
17:35:04 <StellaMitchell> StellaMitchell has joined #rif
17:35:37 <sandro> Yes, DaveReynolds, we've started.
17:35:42 <sandro> zakim, who is on the phone
17:35:42 <Zakim> I don't understand 'who is on the phone', sandro
17:35:44 <sandro> zakim, who is on the phone?
17:35:44 <Zakim> 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
17:35:54 <csma> 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.
17:38:12 <sandro> sandro: Agreed, print should not be in Core.
17:38:51 <sandro> sandro: syntactically it's an external predicate.
17:41:43 <sandro> sandro: Is Print specified in PRD or DTB? I think it should be in DTB -- but only for PRD.
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
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.
17:43:05 <sandro> sandro: .... in the very-small section of PRD which lists the executable predcatices.
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
17:43:29 <Harold> 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.
17:44:05 <csma> 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.
17:46:59 <MichaelKifer> csma: 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
17:47:46 <MichaelKifer> the sentiment seems to be to keep this in PRD.
17:48:23 <cke> +1
17:48:45 <sandro> sandro: So PRINT requires a new kind of test case, with a notion of an output stream.
17:49:28 <cke> 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.
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.
17:50:46 <ChrisW> +1
17:50:56 <Harold> +1
17:51:05 <DaveReynolds> +1
17:51:16 <MichaelKifer> +1
17:51:19 <AxelPolleres> +1
17:51:19 <sandro> +1
17:51:35 <csma> action: chrisw to close issue 62
17:51:35 <trackbot> Sorry, couldn't find user - chrisw
17:51:50 <ChrisW> action: PRD editors to add eggsecute, modify, and print to prd
17:51:50 <trackbot> Sorry, couldn't find user - PRD
17:52:03 <ChrisW> 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].
17:52:31 <sandro> sandro: what can you print?
17:52:45 <csma> action: welty to close issue 62
17:52:45 <trackbot> 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
17:53:15 <csma> egg est cute
17:53:54 <ChrisW> TOPIC: datatype IRIs etc break-in
17:54:22 <MichaelKifer> chrisw: report on the IRI identifier breakout
17:54:58 <ChrisW> 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
17:57:56 <sandro> Looking at: http://www.w3.org/2005/rules/wg/meeting/2009-04-16#line0148
17:59:23 <sandro> isLiteralOfCoreType(...)
18:00:48 <sandro> gary: syntactic vinegar
18:02:24 <GaryHallmark> I like (c)
18:06:54 <MichaelKifer> DaveR: 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.
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.)
18:08:38 <sandro> (well, it would show up as a strictness violation, maybe. I dunno.)
18:08:46 <MichaelKifer> 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.
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)
18:09:46 <AxelPolleres> currently we have as a naming convention for guards: pred:is<i>DATATYPE</i>, pred:isNot<i>DATATYPE</i>
18:09:50 <MichaelKifer> +1
18:09:53 <DaveReynolds> 0
18:09:55 <Harold> +1
18:09:58 <sandro> +1
18:10:03 <AdrianP> 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
18:10:48 <ChrisW> action: Chris to close issue-93
18:10:48 <trackbot> 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)
18:11:04 <GaryHallmark> naming? pred:is-literal-and-not-integer
18:11:25 <sandro> 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
18:12:12 <AxelPolleres> xs:integer(X, true^^boolean) , xs:integer(X, false^^boolean)
18:13:51 <sandro> the second arg is whether it's pos or neg.
18:15:27 <sandro> pred:isLiteralNotInteger(...)
18:15:56 <sandro> 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.
18:19:05 <AxelPolleres> http://www.w3.org/2005/rules/wiki/DTB#Guard_Predicates_for_Datatypes (current version)
18:19:14 <MichaelKifer> 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.
18:19:36 <sandro> 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
18:20:23 <josb> +1 OPTION-2
18:20:37 <sandro> "non-"
18:20:54 <DaveReynolds> The literal predicates should be named by encoding in the whitespace language: http://compsoc.dur.ac.uk/whitespace/ :-)
18:22:39 <johnhall> johnhall has joined #rif
18:23:55 <GaryHallmark> 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.
18:27:06 <GaryHallmark> dave, yes, #4 is Axel's
18:28:33 <sandro> OPTION-1
18:28:41 <GaryHallmark> +1 for #2
18:28:52 <AxelPolleres> 4) followed by 1)
18:28:55 <MichaelKifer> 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")
18:33:47 <ChrisW> 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].
18:33:52 <sandro> (from verbal discussion, using writing on note-pad.)
18:34:38 <MichaelKifer> discussion of Prefix, Base, Import
18:35:06 <MichaelKifer> proposal was to use IRI unicode strings delimited with <...>
18:35:30 <MichaelKifer> Base and Import cannot use curies
18:36:05 <MichaelKifer> 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.
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.
18:37:39 <josb> +1
18:37:40 <sandro> 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.
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.
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
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.
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).
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.....?
18:43:52 <sandro> Chrisw: We say you shouldn't process imports where you don't know the profile
18:43:54 <ChrisW> +1
18:44:01 <GaryHallmark> +
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).
18:44:06 <csma> ++
18:44:51 <sandro> 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
18:45:32 <ChrisW> +1
18:45:34 <Harold> +1
18:45:34 <AdrianP> 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.)
18:45:53 <sandro> -0 it makes parsing more annoying
18:46:05 <ChrisW> 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].
18:46:23 <GaryHallmark> 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.)
18:46:55 <GaryHallmark> reason: same as Sandro
18:47:07 <ChrisW> 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].
18:47:10 <sandro> (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
18:49:06 <csma> 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.
18:49:16 <sandro> issue-97?
18:49:16 <trackbot> 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
18:49:21 <csma> 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
18:50:12 <AxelPolleres> +1
18:50:14 <josb> +1
18:50:23 <johnhall> +1
18:53:36 <csma> ISSUE-96?
18:53:36 <trackbot> 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
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...
18:53:46 <csma> ...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.
18:54:42 <ChrisW> PROPOSED: close ISSUE-96 without action
18:54:46 <ChrisW> +1
18:54:53 <MichaelKifer> +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
18:55:07 <Harold> +1
18:55:09 <ChrisW> action: chris to close issue-96
18:55:09 <trackbot> Created ACTION-757 - Close issue-96 [on Christopher Welty - due 2009-04-23].
18:55:17 <AxelPolleres> +1
19:14:06 <sandro> http://www.w3.org/2009/CommonScribe/panel/
19:21:54 <csma> Dave, we are about to reconvene
19:21:55 <sandro> http://www.w3.org/2005/rules/wiki/Lists
19:22:27 <ChrisW> ok
19:23:04 <csma> http://www.w3.org/2005/rules/wiki/Lists#List_Builtins
19:24:31 <sandro> subtopic: # empty(L)
19:26:01 <sandro> csma: drop it because we don't need it. keep the list short.
19:26:14 <josb> empty(l) equiv l=Seq()
19:26:58 <DaveReynolds> ?? Do we still have Seq() I thought we had builtins only
19:27:15 <josb> we have ground lists
19:27:20 <josb> and Seq() is a ground list
19:27:41 <csma> empty(L) == count(L) = 0
19:29:32 <DaveReynolds> It should be a literal rather than this special syntax surely
19:30:19 <DaveReynolds> +1 to be a builtin
19:30:43 <Harold> Predicates:
19:30:56 <Harold> Scrap empty, exists, deep-equal
19:31:03 <Harold> Functions:
19:32:20 <Harold> s/Functions:/Change name of is-literal-not-list/
19:34:04 <Harold> Rename contains
19:36:30 <Harold> Want it: 7
19:36:43 <DaveReynolds> contains is ok by me
19:40:10 <Harold> contains( Seq( a Seq(1 2 3) b ) Seq(1 2 3) ) returns true
19:40:24 <Harold> Functions:
19:41:52 <Harold> concatenate( Seq( a b ) Seq(1 2 3) ) returns Seq( a b 1 2 3)
19:42:44 <Harold> concatenate is accepted.
19:43:21 <DaveReynolds> index-of seems reasonable to me
19:43:38 <csma> q?
19:44:01 <csma> ack axel
19:49:32 <DaveReynolds> 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?
19:50:36 <DaveReynolds> Yes - head, tail and cons would be nice :-)
19:53:16 <DaveReynolds> inclined to remove avg - sum, just have reduce
19:53:41 <DaveReynolds> q+
19:54:21 <DaveReynolds> q-
19:56:47 <DaveReynolds> no to distinct-values, redundant
19:57:47 <DaveReynolds> +1 to get
19:58:20 <DaveReynolds> -1 to flatten
19:58:45 <DaveReynolds> -1 to sort
20:05:58 <sandro> chrisw: lists are on anything.
20:06:08 <AxelPolleres> Axel: What about defining lists only for literals (maybe nested), but not for arbitrary terms?
20:06:31 <AxelPolleres> ... would this restriction be reasonable, sufficient for the common use cases people have in mind.
20:06:35 <DaveReynolds> +0.5 for map
20:08:13 <sandro> sandro: If you can't define your own functions, map is useless.
20:08:28 <sandro> gary: No, it's good for casting.
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.
20:11:12 <DaveReynolds> -1 to sort
20:11:17 <DaveReynolds> -1 to sort/2
20:12:12 <DaveReynolds> -0.5 to delete
20:12:45 <DaveReynolds> -1 to compare
20:16:29 <csma> q?
20:17:05 <Harold> Chrisw: Can the remaining list preds/funcs be (easily) implemented?
20:17:16 <josb> http://www.w3.org/2005/rules/wiki/Lists#Semantics
20:22:14 <sandro> jos: russel's paradox...?
20:31:19 <ChrisW> Issue-99?
20:31:19 <trackbot> 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
20:31:35 <ChrisW> Scribe: AdrianP
20:34:00 <sandro> sandro: we agree functions in the head are just syntactic sugar,....
20:34:15 <AdrianP> Jos: well-formed formulas - cannot use functions
20:34:17 <sandro> that is EXTERNALS.
20:35:17 <Harold> Harold has joined #rif
20:35:55 <AdrianP> Jos: 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.
20:37:52 <AdrianP> Harold: 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.
20:39:14 <AxelPolleres> AxelPolleres has left #rif
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.
20:39:40 <josb> 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
20:41:09 <AdrianP> Chrisw: add external functions to 2.3 first bullet
20:41:39 <AxelPolleres> AxelPolleres has joined #rif
20:41:48 <GaryHallmark> +1
20:42:49 <AdrianP> csma: 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.
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
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
20:45:46 <AdrianP> +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
20:46:01 <johnhall> +1
20:46:03 <ChrisW> issue-100?
20:46:03 <trackbot> ISSUE-100 -- Add and back into Core conclusion -- OPEN
20:46:03 <trackbot> http://www.w3.org/2005/rules/wg/track/issues/100
20:46:14 <sandro> close issue-99
20:46:14 <trackbot> 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
20:47:10 <ChrisW> dave - are you going to make the edit to CORE?
20:47:11 <AdrianP> csma: resolved to allow conjunctions in the head for BLD
20:47:29 <sandro> 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.)
20:48:10 <sandro> +1
20:48:23 <ChrisW> 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].
20:48:26 <DaveReynolds> +1
20:48:30 <ChrisW> +1
20:48:31 <josb> +1
20:48:37 <AxelPolleres> +1
20:48:41 <sandro> RESOLVED: Conjunction in the head is in Core, closing ISSUE-100. (this probably isn't a change; just being sure.)
20:48:44 <sandro> close issue-100
20:48:44 <trackbot> ISSUE-100 Add and back into Core conclusion closed
20:49:46 <AdrianP> next topic: lists
20:49:50 <AdrianP> michael: how to define count for lists
20:50:17 <AdrianP> http://www.w3.org/2005/rules/wiki/Lists
20:51:35 <Harold> Harold has joined #rif
20:54:30 <DaveReynolds> It's had to follow the discussion without a screen so I'll sign off.
20:54:44 <DaveReynolds> Have a good evening.
20:54:52 <Zakim> -DaveReynolds
20:55:40 <Zakim> -MIT-G631
20:55:41 <Zakim> SW_RIF(F2F)8:00AM has ended
20:55:42 <Zakim> Attendees were DaveReynolds, ChrisW, csma, Harold, MichaelKifer, AdrianP, SaidTabet, cke, johnhall, AxelPolleres, josb, GaryHallmark, StellaMitchell, +45.44.1.aaaa
21:42:42 <sandro> Do we allow: List(1, external(numeric-add(1, ?x)), 3)
21:42:47 <sandro> Jos says No.
21:43:09 <sandro> Axel says if they do, in core, we might as well have function terms in Core.
21:44:26 <sandro> Sandro says: you can emulate it with insert-before
21:49:04 <MichaelKifer> MichaelKifer has left #rif
21:54:07 <Harold> ?x = List( | ?r) tests if ?x is a list.
21:54:51 <sandro> by taking out the negative guard, not-a-list (atomic) the user cannot implement flatten.
21:55:00 <sandro> everyone: uh, yeah.... oh well.
22:08:59 <ChrisW> rrsagent, make minutes
22:08:59 <RRSAgent> I have made the request to generate http://www.w3.org/2009/04/16-rif-minutes.html ChrisW
22:23:23 <AdrianP> http://www.w3.org/2005/rules/wiki/Modify
22:27:33 <StellaMitchell> StellaMitchell has joined #rif
22:53:23 <Zakim> Zakim has left #rif
# SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000591