03:00:30 ericP has left #rif 04:09:15 Zakim has left #rif 13:17:45 RRSAgent has joined #rif 13:17:45 logging to http://www.w3.org/2009/04/16-rif-irc 13:18:01 GaryHallmark has joined #rif 13:18:19 zakim, this is rif 13:18:19 ok, ChrisW; that matches SW_RIF(F2F)8:00AM 13:19:07 Meeting: RIF F2F13 13:19:14 cke has joined #rif 13:19:19 Chair: Chris Welty and Christian de Sainte-Marie 13:19:40 Agenda: http://www.w3.org/2005/rules/wiki/F2F13#Agenda 13:19:49 Scribe: cke 13:20:01 rrsagent, make minutes 13:20:01 I have made the request to generate http://www.w3.org/2009/04/16-rif-minutes.html ChrisW 13:20:25 the subject is core safeness 13:21:19 zakim, MIT-G631 contains ChrisW, csma, Harold, MichaelKifer, AdrianP, SaidTabet, cke, johnhall, AxelPolleres, josb, GaryHallmark, StellaMitchell 13:21:19 +ChrisW, csma, Harold, MichaelKifer, AdrianP, SaidTabet, cke, johnhall, AxelPolleres, josb, GaryHallmark, StellaMitchell; got it 13:21:28 looking at safety definition. How to extend to strongly safe ruleset. 13:21:33 dave, can you hear Axel? 13:21:53 we need disjonction in the body for this 13:23:10 if we limit lists to pure extracion operations, they will be safe 13:23:46 q+ 13:24:17 stabet has joined #rif 13:24:18 q- 13:24:58 built-in for lists raise problems for Core 13:25:15 q+ 13:25:38 stabet has joined #rif 13:26:10 if the strong safeness is almost useless because of the lists,let's forget it 13:28:37 the defeinition can be changed into more elegant 13:28:46 MichaelKifer has joined #rif 13:29:29 we are talking about strong safeness only 13:30:05 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 (March 10 telecon) 13:31:15 there will be only one safeness definition in core, and will be this one 13:31:29 nice to have this new definition today 13:31:35 q? 13:31:45 ack DaveReynolds 13:34:50 need some examples to understand the scope/definition of each concept 13:41:04 q? 13:41:33 this one is safe, but not strongly safe: http://www.w3.org/2005/rules/wiki/Core_Safeness 13:42:10 I would just make a note, give a name, ... 13:43:01 cke, use this syntax: 13:43:09 axel: I would just make a note 13:43:18 (use : not <>) 13:43:27 csma: if some engines won't acept the rulesets which are not strongly safe 13:44:18 axel: we can put it as non normative, we need to provide a way to hav a claim 13:46:46 csma: i do not understand the impact of the restriction. We need to understand the exact impacts 13:48:05 hb: in BLD, there are notions of conformance, strong and weak 13:48:37 hb: we could have a default conformance notion 13:49:00 THat one would nopt be strongly safe: http://www.w3.org/2005/rules/wiki/Chaining_strategy_numeric-add_2 13:49:52 dave: strong safety should not be normative, just informative 13:50:11 sense of room: many agreeing with Dave 13:50:17 chris: what does informative means? (if we put this as informative) 13:51:32 PROPOSED: strong safety would be an informative note (not at risk) in Core, changing previous resolution 13:51:39 isn't "non-normative" the right word to be used in W3C docs? 13:52:14 +1 13:52:15 +1 13:52:17 +1 13:52:19 RESOLVED: strong safety would be an informative note (not at risk) in Core, changing previous resolution 13:52:28 +1 13:52:44 +1 13:52:49 +1 13:52:58 +1 13:53:08 action: axel to draft E-S safety and make informative instead of at-risk 13:53:08 Created ACTION-749 - Draft E-S safety and make informative instead of at-risk [on Axel Polleres - due 2009-04-23]. 13:53:59 csma: 10mn on list built-ins 13:54:15 http://www.w3.org/2005/rules/wiki/Lists#List_Builtins 13:56:48 q? 13:58:26 sandro has joined #rif 13:58:34 sandro: we discussed the built-in in the wiki page 14:00:36 RRSAgent, pointer? 14:00:36 See http://www.w3.org/2009/04/16-rif-irc#T14-00-36 14:00:41 mf: do we add them to prd, or to core? 14:03:48 q+ 14:04:05 RIF-FLD reserves the following symbols for standard aggregate functions: min, max, count, avg, sum, prod, set, and bag. 14:04:48 http://www.w3.org/2005/rules/wiki/FLD#Alphabet 14:06:22 What about get-first(L), get-last(L), get-element-at(L,I)? 14:06:45 Axel - exactly what I was on the queue to mention 14:07:42 we discuss if we add set and bag. set removes duplicates 14:09:23 q+ 14:09:32 Could identify function by anyURI 14:09:44 Horrid but legal 14:11:00 L1, L2) 14:11:27 who is scribe? 14:11:33 sorry I meant to say: how about adding is-sublist? 14:11:47 i'm scribe 14:12:35 we discuss some other builtins: getFirst, getLast, getElement, etc 14:12:59 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 get(-1) == getLast, get(0) == getFirst 14:15:13 chris: 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 Could pass an anyURI which identifies the function. Not nice but could be defined in a workable way. 14:17:10 do we need sort? 14:18:50 josb has joined #rif 14:21:53 there may be a solution to implement map/reduce. we can pass a code for a function 14:22:10 15mn break 14:23:49 reduce(function, iterable[, initializer])¶ 14:23:49 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 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 dave? 14:39:18 zakim, who is on the phone? 14:39:18 On the phone I see DaveReynolds, MIT-G631 14:39:19 MIT-G631 has ChrisW, csma, Harold, MichaelKifer, AdrianP, SaidTabet, cke, johnhall, AxelPolleres, josb, GaryHallmark, StellaMitchell 14:43:04 MichaelKifer has joined #rif 14:43:07 Scribe: StellaMitchell 14:43:38 isLiteralOfType 14:43:43 Jos: problem is how to identify datatypes, this is a result of the above predicate 14:44:23 ...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 isLiteralOfType("1"^^integer, xs:int) 14:45:24 ..rif:iri is one possibility, but it is kludgy. Above example illustrates... 14:46:00 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 ...different results depending on whether or not you support the datatye 14:46:50 p(?x) :- isLiteralOfType("1"^^int, ?x) 14:47:39 Jos: in the above example need to check all possible assignments of ?x 14:48:07 It would return false not an error so that rule would be ok. 14:48:08 ...for some values, it will be unspecified according to DTB and good practice would be to raise an error 14:48:40 GaryHallmark has joined #rif 14:48:54 mk: join of two predicates? 14:48:58 p(?x) :- q(?x), isLiteralOfType("1"^^int, ?x) 14:49:26 We already have invisible extensions surely, if you add predicates existing rule sets potentially break. 14:49:40 Axel: all the current dialects support all the datatypes specified in DTB 14:50:02 if you add predicates, you change the syntax, so the extension is not invisible 14:50:11 johnhall has joined #rif 14:50:24 No 14:50:37 Michael: the point of the isLiteralOfType predicate was to allow for extensibility 14:50:58 csma has joined #rif 14:50:58 Axel: So people who exchange rules need to negotiate ahead of time what the datatypes are 14:52:10 Harold has joined #rif 14:52:16 Dave: some iris are diallowed, eg.external functions 14:52:44 That is why we have External schemata. 14:52:57 Axel: no, we don't disallow any. There is a special syntax to indicate external functions 14:53:04 rrsagent, make logs public 14:53:22 TOPIC: IRIs for datatypes (etc) 14:53:25 Sandro: But in BLD each IRI can only be used in one context 14:55:22 DaveReynolds, is today's speaker phone better or worse than yesterday's? Shall I switch back to yesterday's? 14:55:29 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 Michael: Is there something in the Charter about supporting the merging of rulesets? 14:57:44 Sandro: say an extension defines complex numbers, you will get different entailments from a dialect that doesn't define them 14:59:34 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 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 ... so that one could be fixed easily, even if we fall back to per-dt-gurards, right? 15:01:16 That case would be rejected in strict mode anyway, so it is not an invisible extension, it is visible. 15:01:27 Chris: isLiteralOfType allows you to create invisible extensions 15:01:38 Axel: We had 2 reasons for adding this predicate: 15:01:59 ...1. OWL-RL exercise, made the ruleset shorter 15:02:05 the problem is rather isLiteralOfType("1"^^xs:int, foo:complexNumber) 15:02:32 in strict BLD it is false (or undefined), but in some extension that supports foo:complexNumber it is true 15:02:56 isliteraloftype (?X, xs:integer) :- isInteger(?X). 15:04:02 Jos: could use individual guard predicates as well, for the OWL-RL 15:04:30 (Right, Dave, my example is not really a case of an invisible extension) 15:04:54 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 has joined #rif 15:05:50 ... not having it is not a fundamental problem for the OWLRL ruleset 15:06:29 Jos: my understanding that the invisible extension discussion was about the datatypes 15:08:06 GaryHallmark has joined #rif 15:08:12 Chris: the spirit of "no invisible extensions" was to allow for interoperability between dialects we current have and future ones 15:09:18 Michael: Strict BLD should disallow new symbol spaces, because that would allow invisible extensions 15:09:29 sandro: Yeah, that makes sense.... 15:09:39 ...we didn't say it's illegal to write new symbol spaces in BLD 15:09:48 sandro: We didn't realize symbol spaces could be added by users.... 15:10:05 ...but we should now all that restriction for string conformance 15:10:15 s/all/add/ 15:10:23 s/string/strict/ 15:11:28 Chris: what are people's opinions: 15:11:50 s/opinions/opinions on isLiteralOfType/ 15:11:56 Jos: get rid of it 15:12:00 Dave: prefer to keep it 15:12:02 in strict BLD it is false (or undefined), but in some extension that supports foo:complexNumber it is true 15:12:04 the problem is rather isLiteralOfType("1"^^xs:int, foo:complexNumber) 15:12:15 Sandro: not fully understanding all the implications 15:12:25 Axel: I prefer to keep it but see the problems 15:12:26 p(?x) :- q(?x), isLiteralOfType("1"^^int, ?x) 15:13:10 Michael: for above example, some dialects might give an error 15:13:12 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 Jos: a dialect could return false for any datatype that it doesn't recognize 15:14:05 per-document-tags for supported DTs instead of supported DTs per dialect? 15:15:30 Michael: I think this predicate is more trouble than it's worth 15:15:32 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 Chris: Dave, do you mean to have this predicate work only for datatypes defined in DTB 15:16:01 Dave: yes 15:16:17 dave's option b : isLiteralOfCoreType(...) 15:16:23 Chris: so Michael's example would be false for all other datatypes? 15:16:25 Dave: yes 15:18:29 isLiteralOfType(Lit,Type,ListOfDatatytpes) 15:18:53 Chris: each dialect in addition to adding new types, has to define it's own isLiteralOfType, or add individual types 15:19:30 Michael: so the original benefit of this predicate is taken away 15:21:16 Axel: another option in addition to Dave's three above 15:26:09 Jos: a and b leave us with the problem of how to identify datatypes 15:26:49 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: with rif:iri you don't know un-equality.... 15:27:31 Chris: Dave, is we go with a or b, do you care how datatypes are identified? 15:28:34 Dave: prefer string, but Jos's proposal is ok with me 15:29:53 a1 == isLiteralOfTyle(...., foo:bar) is FALSE a2 == isLiteralOfType(...., foo:bar) is unknown/error, but not very useful. 15:30:10 s/unknown/undefined/ 15:30:20 p(?x) :- isLiteralOfType("1"^^int, ?x) 15:31:08 Chris: if we give undefined for unknown datatype, then the predicate is not so useful because cannot be used to extract datatypes 15:31:08 a2 is extension-safe, but you can't write useful rules maybe....? 15:31:09 p("a") :- isLiteralOfType("1"^^int, "a") 15:32:49 sandro: Dave, you just need to trap the exception. 15:32:58 Jos: for unknown datatype, returning false allows worse invisible extensions and returning undefined makes the predicate less useful 15:35:01 the problem with a1 is : the problem is rather isLiteralOfType("1"^^xs:int, foo:complexNumber) 15:35:41 Michael: a seems useless, b leaves problems of datatype identifiers 15:36:00 Jos: now prefer anyURI as datatype identifier 15:37:05 Michael: prefix, import and base...inconistency in how we specify arguments to those 15:37:30 Jos: I prefer IRIs for all of those 15:37:32 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 Chris: everyone happy with IRIs for arguments of prefix, import and base 15:38:18 s/base/base?/ 15:38:23 DaveReynolds: prefix, import, and base are strings which happen to be IRIs. 15:39:11 sandro: Use CURIEs for anyURI ? 15:39:13 kifer: Yes. 15:40:48 You wouldn't use curies for prefix or base! 15:41:05 Sandro: is anyURI a sybtype of string? no it isn't. 15:41:38 Delimiter <...> 15:42:03 Michael: rif:iris cause semantic problems, contants are correct for arguments to import, prefix and base 15:42:25 sandro: on solution - just use strings, instead of anyURI. 15:42:30 ...it they are going to be constants, I prefer anyURI to string 15:42:37 ...but strings are ok 15:43:07 Chris: won't we then have problems with curies? 15:44:52 Dave: prefix, import and base arguments are just strings, and they are a completely different case from the syntax from isLiteralOfType 15:45:57 * Dave is proposing: 15:45:57 * ==> "foo"^^xs:anyURI within Prefix, Base, Import 15:45:57 * ==> "foo"^^rif:uri everywhere else 15:46:41 Dave: arguments to import, base and prefix are not constants in the language 15:47:04 Sandro: we don't need any delimiter then 15:47:43 ...(if we have spaces around parens) 15:48:18 Sandro: wants to use curies for base 15:48:38 prefix this: 15:48:41 base this: 15:48:56 whatever. 15:50:29 Chris: we need delimieters for import, prefix and base. I propose angle brackets because they connote web address 15:50:30 PROPOSED: < > as the delims in Prefix, Base, Import, and be careful not to confuse them with Consts. 15:50:36 everyone: ok 15:51:29 Chris: Do we want a shortcut for xs:anyURIs. 15:51:52 nooooooooooooooooooooooooooooo 15:52:11 sandro: This makes option B goofy/nutty in the PS. 15:52:47 would like isLiteralOfCoreType(?x, xsd:byte) 15:53:01 would like isLiteralOfCoreType(?x, "http:/....#byte"^^xs:anyURI) 15:53:15 s/would like/have to do/ 15:56:23 sandro, you propose isLiteralOfType("1"^^xs:int, xs:integer) is false? 15:57:11 actually, you cannot distinguish between "1"^^xs:int and "1"^^integer 15:57:38 because they denote the same object in the domain (the number one) 15:57:42 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 so, you cannot define isLiteralOfType to do this 15:57:54 sandro, you wouldn't get possibly the behaivour you expect.... 15:57:56 action: michael to restrict use of symbol spaces in compliance section of BLD 15:57:56 Sorry, amibiguous username (more than one match) - michael 15:57:56 Try using a different identifier, such as family name or username (eg. msintek, mkifer, merdmann) 15:58:09 action: kifer to restrict use of symbol spaces in compliance section of BLD 15:58:09 Created ACTION-750 - Restrict use of symbol spaces in compliance section of BLD [on Michael Kifer - due 2009-04-23]. 15:58:33 take isLiteralOfType("1"^^xs:unsignedInteger, ?X) 15:58:58 ... and isLiteralOfType("1"^^xs:integer, ?X), they would ALWAYS need to have the same result. 15:59:25 ... so your "pick-one" proposal wouldn't extract the datatype which was declared in the date necessary. 15:59:51 ... I mean, in the lexical representation of the data. 16:01:20 DaveReynolds, we'll reconvene in 90 minutes. 16:02:22 -DaveReynolds 17:29:07 josb has joined #rif 17:30:24 MichaelKifer has joined #rif 17:31:28 ChrisW has joined #rif 17:31:30 DaveReynolds has joined #rif 17:31:57 hi dave 17:32:30 just getting back into room 17:32:42 topic: PRD break-in 17:32:50 GaryHallmark has joined #rif 17:33:04 Scribe: MichaelKifer 17:33:06 csma has joined #rif 17:33:53 Harold has joined #rif 17:34:02 + +45.44.1.aaaa 17:34:08 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 has joined #rif 17:34:16 cke has joined #rif 17:34:45 AxelPolleres has joined #rif 17:34:55 csma: report on the PRD breakout 17:35:04 StellaMitchell has joined #rif 17:35:37 Yes, DaveReynolds, we've started. 17:35:42 zakim, who is on the phone 17:35:42 I don't understand 'who is on the phone', sandro 17:35:44 zakim, who is on the phone? 17:35:44 On the phone I see MIT-G631, DaveReynolds 17:35:45 MIT-G631 has ChrisW, csma, Harold, MichaelKifer, AdrianP, SaidTabet, cke, johnhall, AxelPolleres, josb, GaryHallmark, StellaMitchell 17:35:54 PROPOSED: add Print as a builtin that can be Executed. 17:36:56 csma: semantically neutral builtin wrapper is one that cannot change the semantics of the rules. 17:38:12 sandro: Agreed, print should not be in Core. 17:38:51 sandro: syntactically it's an external predicate. 17:41:43 sandro: Is Print specified in PRD or DTB? I think it should be in DTB -- but only for PRD. 17:42:50 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 +1 17:43:04 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: .... in the very-small section of PRD which lists the executable predcatices. 17:43:09 +1 17:43:22 +1 17:43:22 +1 17:43:27 +1 17:43:27 +1 17:43:29 1 17:43:32 +1 17:43:35 +1 17:43:37 +1 17:43:44 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 PROPOSED: add Print as a builtin that can be Executed. 17:46:32 PROPOSED: add Print as a builtin that can be Executed. The definition of that buitin goes in PRD. 17:46:59 csma: whether to add the action-builtins to DTB or PRD? 17:47:40 PROPOSED: add Print as a builtin that can be Executed. The definition of that buitin goes in PRD. Closing ISSUE-62 17:47:46 the sentiment seems to be to keep this in PRD. 17:48:23 +1 17:48:45 sandro: So PRINT requires a new kind of test case, with a notion of an output stream. 17:49:28 yes, we need to check that the output of an execution is such and such string 17:49:42 Maybe add at least a 2nd executable right away to show generality. 17:50:39 RESOLVED: add Print as a builtin that can be Executed. The definition of that buitin goes in PRD. Closing ISSUE-62. 17:50:46 +1 17:50:56 +1 17:51:05 +1 17:51:16 +1 17:51:19 +1 17:51:19 +1 17:51:35 action: chrisw to close issue 62 17:51:35 Sorry, couldn't find user - chrisw 17:51:50 action: PRD editors to add eggsecute, modify, and print to prd 17:51:50 Sorry, couldn't find user - PRD 17:52:03 action: csma (PRD editors) to add eggsecute, modify, and print to prd 17:52:03 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: what can you print? 17:52:45 action: welty to close issue 62 17:52:45 Created ACTION-752 - Close issue 62 [on Christopher Welty - due 2009-04-23]. 17:53:09 gary: anything that can be coerced to string -- which is any literal 17:53:15 egg est cute 17:53:54 TOPIC: datatype IRIs etc break-in 17:54:22 chris: report on the IRI identifier breakout 17:54:58 rrsagent, make minutes 17:54:58 I have made the request to generate http://www.w3.org/2009/04/16-rif-minutes.html ChrisW 17:57:56 Looking at: http://www.w3.org/2005/rules/wg/meeting/2009-04-16#line0148 17:59:23 isLiteralOfCoreType(...) 18:00:48 gary: syntactic vinegar 18:02:24 I like (c) 18:06:54 DaveR: does not see invisible extensions caused by isLiteralOfType as a serious problem 18:07:25 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 (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 (well, it would show up as a strictness violation, maybe. I dunno.) 18:08:46 call for objections to option (c)... 18:09:20 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 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 currently we have as a naming convention for guards: pred:isDATATYPE, pred:isNotDATATYPE 18:09:50 +1 18:09:53 0 18:09:55 +1 18:09:58 +1 18:10:03 0 18:10:03 +1 18:10:12 +1 18:10:14 +1 18:10:26 +1 18:10:35 DaveR and Adrian would have preferred to keep the isLiteralOfType guards 18:10:48 action: Chris to close issue-93 18:10:48 Created ACTION-753 - Close issue-93 [on Christopher Welty - due 2009-04-23]. 18:10:51 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 naming? pred:is-literal-and-not-integer 18:11:25 guard:int nguard:int 18:11:28 axel: want to be the names of the guards to be the same as the data type name 18:12:12 xs:integer(X, true^^boolean) , xs:integer(X, false^^boolean) 18:13:51 the second arg is whether it's pos or neg. 18:15:27 pred:isLiteralNotInteger(...) 18:15:56 pred:isLiteralNotInteger(...) and pred:isInteger(...) 18:18:32 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 http://www.w3.org/2005/rules/wiki/DTB#Guard_Predicates_for_Datatypes (current version) 18:19:14 pred:integer and pred:non-integer 18:19:30 OPTION-2: take local part, append to "is-literal-not" and "is-\", ... in pred: OR some other namespace. 18:19:36 OPTION-2: take local part, append to "is-literal-not" and "is-", ... in pred: OR some other namespace. 18:20:07 pred:is-integer pred:is-literal-and-not-integer 18:20:23 +1 OPTION-2 18:20:37 "non-" 18:20:54 The literal predicates should be named by encoding in the whitespace language: http://compsoc.dur.ac.uk/whitespace/ :-) 18:22:39 johnhall has joined #rif 18:23:55 pred:has-a-datatype-but-it-aint-intege 18:26:15 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 dave, yes, #4 is Axel's 18:28:33 OPTION-1 18:28:41 +1 for #2 18:28:52 4) followed by 1) 18:28:55 int non-int 18:33:07 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 action: axel to add guards back to DTB with naming conventions 18:33:47 Created ACTION-754 - Add guards back to DTB with naming conventions [on Axel Polleres - due 2009-04-23]. 18:33:52 (from verbal discussion, using writing on note-pad.) 18:34:38 discussion of Prefix, Base, Import 18:35:06 proposal was to use IRI unicode strings delimited with <...> 18:35:30 Base and Import cannot use curies 18:36:05