IRC log of rif on 2009-04-15

Timestamps are in UTC.

12:33:12 [RRSAgent]: RRSAgent has joined #rif
12:33:12 [RRSAgent]: logging to http://www.w3.org/2009/04/15-rif-irc
12:33:30 [ChrisW]: Meeting: RIF F2F13
12:36:44 [AdrianP]: AdrianP has joined #rif
12:39:55 [ChrisW]: Chair: Chris Welty and Christian de Sainte-Marie
12:40:47 [ChrisW]: Meeting: RIF F2f13 15-Apr-09
12:44:13 [johnhall]: johnhall has joined #rif
12:51:03 [Harold]: Harold has joined #rif
12:54:47 [ChrisW]: Agenda: http://www.w3.org/2005/rules/wiki/F2F13
12:55:00 [ChrisW]: rrsagent, make minutes
12:55:00 [RRSAgent]: I have made the request to generate http://www.w3.org/2009/04/15-rif-minutes.html ChrisW
12:55:33 [csma]: csma has joined #rif
12:55:55 [ChrisW]: rrsagent, make logs public
12:56:29 [josb]: josb has joined #rif
12:57:46 [ChrisW]: ChrisW has changed the topic to: RIF 13th F2F Meeting, Cambridge MA, Agenda http://www.w3.org/2005/rules/wiki/F2F13
13:00:54 [cke]: cke has joined #rif
13:02:26 [sandro]: sandro has joined #rif
13:04:15 [sandro]: RRSAgent, pointer?
13:04:15 [RRSAgent]: See http://www.w3.org/2009/04/15-rif-irc#T13-04-15
13:04:22 [MichaelKifer]: MichaelKifer has joined #rif
13:04:23 [sandro]: scribe: harold
13:05:27 [ChrisW]: zakim, list conferences
13:05:27 [Zakim]: I see T&S_EGOV()9:00AM, Team_W3M()8:00AM, SW_RIF(F2F)8:00AM active
13:05:30 [Zakim]: also scheduled at this time are WAI_ERTWG()8:30AM, DIG_WSRI()8:00AM
13:05:34 [ChrisW]: zakim, this is rif
13:05:35 [Zakim]: ok, ChrisW; that matches SW_RIF(F2F)8:00AM
13:05:41 [ChrisW]: zakim, who is on the phone?
13:05:41 [Zakim]: On the phone I see ??P12, W3C
13:05:53 [ChrisW]: zakim, W3C is temporarily Meeting_Room
13:05:53 [Zakim]: +Meeting_Room; got it
13:08:52 [ChrisW]: zakim, Meeting_Room contains csma, josb, MichaelKifer, AxelPolleres, cke, johnHall, AdrianP, Harold, Gary, sandro, ChrisW
13:08:52 [Zakim]: +csma, josb, MichaelKifer, AxelPolleres, cke, johnHall, AdrianP, Harold, Gary, sandro, ChrisW; got it
13:10:01 [Harold]: Swap April 15/16 Agenda items: Tonight XML Schemas, Tomorrow Issue-93
13:10:30 [GaryHallmark]: GaryHallmark has joined #rif
13:11:25 [Harold]: On April 17 we have to finish at 4PM.
13:12:24 [sandro]: RRSAgent, pointer?
13:12:24 [RRSAgent]: See http://www.w3.org/2009/04/15-rif-irc#T13-12-24
13:13:51 [csma]: http://www.w3.org/2009/04/07-rif-minutes.html
13:13:51 [AxelPolleres]: AxelPolleres has joined #rif
13:14:54 [csma]: PROPOSED: Close ISSUE-86 and ISSUE-87, addressed by the current text of http://www.w3.org/2007/OWL/wiki/InternationalizedStringSpec
13:15:43 [josb]: +1
13:15:46 [sandro]: +1
13:17:34 [josb]: The text: Despite the semantic equivalence between typed rdf:text literals and plain literals, the presence of typed rdf:text literals in an RDF graph might cause interoperability problems between RDF tools, as not all RDF tools will support rdf:text. Therefore, before exchanging an RDF graph with other RDF tools, an RDF tool that suports rdf:text MUST replace in the graph each typed...
13:17:36 [josb]: ...rdf:text literal with the corresponding plain literal. The notion of graph exchange includes, but is not limited to, the process of serializing an RDF graph using any (normative or nonnormative) RDF syntax.
13:17:43 [DaveReynolds]: +1
13:17:46 [josb]: http://www.w3.org/2007/OWL/wiki/InternationalizedStringSpec#Relationship_with_Plain_Literals_and_xs:string
13:17:47 [Harold]: +1
13:18:01 [ChrisW]: +1
13:18:03 [AdrianP]: +1
13:18:22 [AxelPolleres]: +1
13:18:24 [csma]: RESOLVED: Close ISSUE-86 and ISSUE-87, addressed by the current text of http://www.w3.org/2007/OWL/wiki/InternationalizedStringSpec
13:18:39 [ChrisW]: action: chris to close issue-86 issue-87
13:18:39 [trackbot]: Created ACTION-732 - Close issue-86 issue-87 [on Christopher Welty - due 2009-04-22].
13:19:12 [DaveReynolds]: Before or after SPARQL group review?
13:19:18 [csma]: PROPOSED: publish rdf:text as a LC
13:19:21 [josb]: +!
13:19:23 [josb]: +1
13:19:26 [sandro]: +1
13:19:29 [AxelPolleres]: +1
13:19:31 [Harold]: +1
13:19:36 [GaryHallmark]: +1
13:19:45 [AdrianP]: +1
13:19:46 [ChrisW]: +1
13:19:56 [DaveReynolds]: 0
13:20:06 [MichaelKifer]: +1
13:20:56 [ChrisW]: DaveR: Abstain - Would have preferred to get feedback from SparQL first
13:21:06 [csma]: RESOLVED: publish rdf:text as a LC
13:21:30 [ChrisW]: rrsagent, pointer?
13:21:30 [RRSAgent]: See http://www.w3.org/2009/04/15-rif-irc#T13-21-30
13:22:16 [AxelPolleres]: I understand that I can ask SPARQL WG to review next week already?
13:22:57 [sandro]: AxelPolleres, you should probably wait until it's actually published, but... sure, whatever.
13:23:00 [Harold]: Jos: Could we put a possible change from XML Schema 1.0 to XML Schema 1.1 on the agenda?
13:23:54 [Harold]: Sandro: The only reason not to go to XML Schema 1.1 would be that they are in LC (since January).
13:24:15 [Harold]: Jos: Still better than referring to 'broken' one in XML Schema 1.0.
13:24:38 [Harold]: ... Talking about XML Schema DATATYPES.
13:25:29 [sandro]: PROPOSED: We'll use XML Schema Datatypes 1.1 (not XML Schema Datatyoes 1.0) in our specs.
13:25:43 [josb]: +1
13:25:49 [sandro]: Jos: It makes lots of things well defined that are not currently well defined.
13:25:54 [DaveReynolds]: +1
13:26:09 [sandro]: +1
13:28:16 [Harold]: Harold: What about the W3C XML Schema validator XSV? When will it be upgraded?
13:29:40 [Harold]: Sandro: Has been maintained by Henry Thompson.
13:30:39 [Harold]: Harold: XSV is also 'responsible' for validating Datatypes at the 'leaf' level of XML instance trees.
13:31:03 [ChrisW]: ISSUE: Update all specs to reference XML Schema datatypes 1.1
13:31:03 [trackbot]: Created ISSUE-98 - Update all specs to reference XML Schema datatypes 1.1 ; please complete additional details at http://www.w3.org/2005/rules/wg/track/issues/98/edit .
13:31:27 [ChrisW]: topic: ISSUE-95 (List Datatype)
13:37:06 [AxelPolleres]: q+ to ask about connection to rdf:List and accessor built-ins
13:38:58 [DaveReynolds]: q+ to ask about Core
13:40:04 [Harold]: Axel: How are 'Seq lists' related to RDF lists?
13:40:30 [Harold]: ... awkward to have 3 different kinds of lists.
13:40:42 [Harold]: Jos: Lists in RDF have no semantics.
13:41:12 [Harold]: http://www.w3.org/2005/rules/wiki/Lists#Semantics
13:44:31 [Harold]: Christian: Content of an XML list cannot be complex.
13:45:18 [AxelPolleres]: If we doe the semantics purely in terms of pairs, then it would be closer to RDF lists.
13:45:22 [Harold]: ... Non-ground lists would not be allowed in PRD.
13:45:36 [AxelPolleres]: ... Harold, you confirmed this (?)
13:46:40 [Harold]: I think, yes.
13:46:53 [josb]: eeeeeh RDF lists dont have semantics, so how can our semantics be close to that?
13:47:34 [johnhall]: johnhall has joined #rif
13:48:01 [Harold]: Christian: What about Forall ?x IF p(Seq(a ?x c)) THEN ...
13:48:43 [AxelPolleres]: jos, it would be nice to be able to - at least - convert between well-formed RDF lsits and RIF lists, that might be possible with a bunch of RIF rules... like constructing lists in Prolog.
13:49:55 [GaryHallmark]: PRD should have no problem with vars in lists provided the rule is safe
13:50:50 [Harold]: Harold: Only difference is if the above ?x is universal (as above) or existential.
13:50:56 [sandro]: PRD will not actually handle unbound variables stored in a list.
13:51:13 [sandro]: cke: List contain concrete values
13:51:23 [GaryHallmark]: ... begging the question, what are the safe binding patterns for List
13:51:45 [Harold]: Harold: Existential in queries.
13:52:38 [DaveReynolds]: q+
13:53:09 [Harold]: Christian: What about Forall ?x IF Seq(a ?x c) = Seq(?y c b) THEN ...
13:54:23 [Harold]: Harold: ?y is existential here.
13:54:58 [ChrisW]: ack axel
13:54:58 [Zakim]: AxelPolleres, you wanted to ask about connection to rdf:List and accessor built-ins
13:55:00 [ChrisW]: ack dave
13:55:00 [Zakim]: DaveReynolds, you wanted to ask about Core and to
13:55:06 [johnhall]: johnhall has joined #rif
13:55:42 [Harold]: Dave: What does this mean for safeness?
13:55:59 [Harold]: Michael: We have to extend the safeness condition for lists.
13:56:25 [Harold]: Dave: Disguised function symbols in Core.
13:56:26 [josb]: Dave, we would not allow variables in lists in the head
13:56:32 [josb]: and perhaps also not in the body
13:57:01 [josb]: (in Core)
13:58:24 [Harold]: Harold: Dave is saying you can encode functions using lists, eg the first element of a list could be the function symbol, the remaining ones its arguments.
13:59:25 [Harold]: Michael: Need to think more about it. Still, we could extend the safeness condition to lists.
13:59:52 [Harold]: Christian: How implemented in JRules etc.?
14:00:08 [DaveReynolds]: It seems to me if you can't construct new lists they are pointless, if you can that you can have non-terminating generation of recursive datastructures. That would preclude datalog engines and the notion of strong safety. OK by me but seems like a bit change.
14:00:24 [DaveReynolds]: s/bit/big/
14:01:04 [Harold]: Changhai: Yes, can be implemented.
14:02:40 [Harold]: Michael: If we don't allow open lists in the head, and are always smaller than in the body, then it could be in Core.
14:03:29 [Harold]: Jos: Better: no lists in Core.
14:04:13 [Harold]: Axel/Sandro/Gary: Emulate lists with built-ins.
14:04:15 [sandro]: sandro: This is just another builtin.
14:04:27 [sandro]: sandro: (as far as Datalog/Core is concerned.)
14:04:36 [Harold]: s/can be implemented/can be implemented, but would be rather advanced/
14:05:08 [Harold]: Axel: Do we really need (these 'amputated') lists in Core?
14:05:46 [Harold]: ... Cause we could have the distinguished function Pair symbol.
14:06:04 [Harold]: Changhai: What about disjunctions?
14:06:17 [Harold]: ... Lists that mostly would be constant.
14:07:37 [Harold]: Christian: For all customers, if ?x is the bank account list and length of ?x is greater than 3 ....
14:07:59 [Harold]: ... You still need some kind of list type.
14:08:32 [Harold]: ... To check that there is this (finite) list of the customers' bank account.
14:09:29 [Harold]: ... Would it be advisable to have some list processing operators in Core, and then have list terms in BLD and (slightly different) in Core?
14:09:56 [Harold]: Jos: Will lead to discrepancy with BLD.
14:10:15 [Harold]: Sandro: Data could come from RDF.
14:10:28 [Harold]: ... List operators would be in Core.
14:11:50 [Harold]: Christian: You could write Forall ?x ?y IF ?x{Att->?y] AND func:length(?y) < 3
14:12:30 [Harold]: ... without needing to completely define what the list ?y actually is.
14:12:42 [Harold]: Michael: Semantics would still be provided.
14:13:13 [Harold]: Christian/Sandro: Would not need to defined in Core, only in BLD and PRD.
14:13:30 [Harold]: Gary: May make sense.
14:13:47 [Harold]: Christian: In DTB.
14:14:12 [Harold]: Gary: You have to say it's a list, just as it could be an integer etc.
14:14:31 [Harold]: ... (but not give details)
14:14:54 [Harold]: Sandro: Confused why you cannot construct lists in Core.
14:15:58 [Harold]: Jos: Christian proposes special lists in Core.
14:16:16 [Harold]: Michael: You can allow ground lists in Core.
14:16:39 [Harold]: Chris: Head and body?
14:16:46 [Harold]: Michael: Yes.
14:17:07 [Harold]: Gary: But it should be something useful.
14:17:38 [Harold]: Chris: No variables inside lists.
14:19:36 [Harold]: Christian: Forall ?x ?y IF Seq(a b c) = ?y would be allowed?
14:19:40 [Harold]: Michael: Yes.
14:21:13 [Harold]: Harold: OK, let's introduce Core ground lists plus their built-ins.
14:21:14 [DaveReynolds]: Gary - we don't non-termination, that's the whole E-S strong safety!
14:22:17 [GaryHallmark]: dave, is E-S harder to spec with lists than with e.g. numeric-add?
14:22:48 [DaveReynolds]: Gary - the point is that E-S eliminates all useful constructions of lists.
14:23:15 [Harold]: Christiann: Forall ?x ?y IF Seq(a ?x c) = ?y AND ?x =b
14:23:35 [DaveReynolds]: Gary - If you want useful list construction just have Jos' safety construction and drop the goal of allowing datalog engines.
14:23:53 [Harold]: ... Groundability could be handled like the safeness condition.
14:24:59 [ChrisW]: q?
14:25:45 [Harold]: Harold: 'Save groundability' notion could be introduced, even if 'conservative' (not catching all groundable cases): Better than only 'plain' ground lists.
14:27:16 [DaveReynolds]: Could the list of options go in the minutes?
14:27:28 [Harold]: Christian: Three options on whiteboard: One is a short version of the above.
14:27:53 [Harold]: 12 mins break now.
14:28:21 [sandro]: RRSAgent, pointer?
14:28:21 [RRSAgent]: See http://www.w3.org/2009/04/15-rif-irc#T14-28-21
14:28:44 [GaryHallmark]: I sense one problem is that I would like to see Core grow to the intersection of PRD/BLD and others would like ot see it shrink to finite models only...
14:28:57 [GaryHallmark]: s/ot/to
14:28:59 [Harold]: Christian's three options:
14:29:18 [Harold]: 1) Ground lists + builtins in Core
14:30:15 [DaveReynolds]: Gary - agreed. That was the whole debate over this E-S strong safety notion. I'd be happy to have a non-termination in Core and have usable lists.
14:33:26 [AxelPolleres]: FYI: The reference to XML Schema DT 1.1 in rdf:text has been fixed
14:33:36 [Harold]: 2) Safe lists (no unbound var inside lists) + builtins in Core
14:34:16 [Harold]: 3) Same as 2) but PRD (no lists in Core)
14:35:02 [Zakim]: -DaveReynolds
14:36:47 [Zakim]: +??P4
14:36:50 [Zakim]: -Meeting_Room
14:36:51 [Zakim]: +Meeting_Room
14:37:15 [Harold]: Harold: Christian's option 2) corresponds to above 'safe groundability'.
14:42:30 [ChrisW]: scribe: AdrianP
14:42:43 [ChrisW]: TOPIC: Issue-94 (Objects)
14:43:02 [ChrisW]: zakim, who is on the phone?
14:43:02 [Zakim]: On the phone I see Meeting_Room, DaveReynolds
14:43:03 [Zakim]: Meeting_Room has csma, josb, MichaelKifer, AxelPolleres, cke, johnHall, AdrianP, Harold, Gary, sandro, ChrisW
14:43:05 [AdrianP]: csma: sent slides
14:45:23 [AdrianP]: Harold: we discussed a year ago that OWL cardinality constraints can be used
14:46:32 [AdrianP]: Harold: not defined in RIF, delegate to OWL, for instance
14:47:13 [AdrianP]: csma: in PRD the is action modify which has semantics of assert with replacement semantics
14:47:14 [sandro]: csma: action MODIFY is like assert, but with replacement semantics.
14:49:04 [AdrianP]: csma: modify = replace all the values and assert new ones
14:49:12 [sandro]: new ONE
14:50:40 [AdrianP]: cke: object model can be changed in option 4
14:51:20 [AdrianP]: csma: interchange object model can be outside of RIF, e.g. in UML or XML Schema
14:52:21 [AdrianP]: Gary: frames are general; need to be mapped into a concrete data model;
14:52:48 [AdrianP]: Gary: do some analysis and figure out the implied data model
14:53:57 [AdrianP]: Gary: declare the data types and constraints - then you don't need the complex analysis
14:54:06 [AdrianP]: Sandro: why not option 5
14:54:38 [AdrianP]: Gary: option 5 does not ensure interoperability
14:55:10 [sandro]: csma: Option 5.5 -- have a standard metadata field for linking to an XML Schema
14:55:25 [AdrianP]: Gary: data model might not be XML schema
14:55:48 [AdrianP]: Chris: option 6 you would need to duplicate the data model in RIF
14:56:27 [AdrianP]: Michael: agree with Gary- if something is specified out of RIF but affects the semantics
14:56:56 [AdrianP]: Gary: like to have syntax where you know the semantics
14:57:30 [AdrianP]: Gary: like to explicitly know how to translate it into the specific execution data model
14:58:47 [AdrianP]: Harold: multi-valued treated like a set
14:58:56 [AdrianP]: Harold: replace the whole set with a new one
14:59:11 [AdrianP]: Harold: single-valued is a special case
14:59:34 [AdrianP]: Harold: like in F-Logic
14:59:55 [AdrianP]: Michael: in F-Logic you have types which indicate that
15:00:51 [AdrianP]: Sandro: seems to be reasonable that type information is additionally provided
15:01:02 [sandro]: Gary: I'm not saying type infpormation should be mandatory, just that it should be possible to supply.
15:01:29 [AdrianP]: csma: why not using existing syntax for describing the data model?
15:01:51 [AdrianP]: Gary: should be specified in the language we are using, i.e. RIF
15:01:58 [sandro]: Gary: I want to specified my RIF data model using RIF constructs.
15:02:17 [AdrianP]: csma: what about a mapping von XML Schema to RIF
15:02:49 [AdrianP]: Gary: cardinality constraints seem to be a very small extension of the RIF syntax
15:03:04 [AdrianP]: Gary: we should provide this expressiveness in RIF
15:03:05 [Harold]: PRD's Modify construct would just be a special case by replacing a singleton-set value; BLD could also be extended with a Modify construct, which would replace general set values.
15:03:25 [AdrianP]: cke: in XML schema we have all this kind of expersivness
15:04:59 [AdrianP]: Gary: but not solved in RIF
15:05:28 [AdrianP]: csma: impacts the semantics of rules or not?
15:05:54 [AdrianP]: csma: seems to me that it is external to RIF
15:05:58 [sandro]: (It doesn't affect the entailments. It may affect type-errors and performance.)
15:07:34 [DaveReynolds]: Surely it does affect entailments. If you say "slot s has cardinality 1" then a rule o[s->"a", s->"b"] would raise and error.
15:07:38 [DaveReynolds]: s/and/an/
15:07:58 [AdrianP]: Gary: option 6 introduce singleton and set to distinguish
15:08:23 [AdrianP]: Sandro: may affect type checking, performance, ...
15:09:24 [AdrianP]: cke: option 6 example is this information part of the rule?
15:09:32 [AdrianP]: Gary: yes
15:10:12 [AdrianP]: Michael: how to define interoperability?
15:10:24 [AdrianP]: Gary: would be like type checking
15:10:56 [AdrianP]: Gary: basically like a constraint
15:11:17 [AdrianP]: Gary: this example is only for frames
15:11:37 [Harold]: PRD: Given single-valued obj[slot->oldval], the statement Modify(obj, slot, newval) leads to obj[slot->newval].
15:11:50 [Harold]: BLD: Given multi-valued obj[slot->oldval1] AND ... AND obj[slot->oldvalN], i.e. obj[slot->{oldval1, ..., oldvalN}], the statement Modify(obj,slot,newval) also leads to obj[slot->newval].
15:12:35 [AdrianP]: csma: will lead us to a new data model language
15:12:58 [AdrianP]: csma: all this already exists in othere languages
15:13:50 [StellaMitchell]: StellaMitchell has joined #rif
15:15:03 [AdrianP]: Chris: sounds like option 4
15:16:29 [Harold]: My proposal is compatible with option 4.
15:17:53 [Harold]: (Without need fro static analysis)
15:18:13 [Harold]: Just add a modify operator that ALWAYS replaces ALL values.
15:18:46 [Harold]: (ALWAYS: in PRD and all follow-up languages extending BLD)
15:19:26 [AdrianP]: csma: first two options mean add information explicitly
15:19:59 [AdrianP]: csma: three is use a new construct for different multiplicity
15:20:04 [Harold]: When I wrote "BLD: Given multi-valued ..." I meant a future BLD extension allowing a Modify.
15:20:15 [AdrianP]: csma: 4 and 5 ignore
15:20:30 [AdrianP]: csma: 6 include some external description
15:20:55 [AdrianP]: csma: 5 include some external description
15:21:08 [AdrianP]: csma: 6 add syntax to RIF
15:21:56 [AdrianP]: Michael: out-of-band does not make sense from the point of interoperability
15:22:29 [AdrianP]: Chris: option 5 relies on other external mechanism
15:25:43 [AdrianP]: Sandro: Gary, would a new error type work for you?
15:27:05 [AdrianP]: Gary: PRD you can directly indicate errors
15:29:03 [GaryHallmark]: example of constraint rules: http://lists.w3.org/Archives/Public/public-rif-wg/2009Mar/0135.html
15:29:14 [AdrianP]: Michael: thought the problem was, that Gary sees problems when you translate Core into PRD
15:30:12 [AdrianP]: Gary: for instance should be able to say that a person only have one birthday
15:30:34 [AdrianP]: Gary: should be able to explicity say this in terms of a cardinality constraint
15:31:07 [AxelPolleres]: isn't modify just delete all existing values and add the new value?
15:32:49 [sandro]: chris: The issue is: Should we have Cardinality Constraints (and perhaps Type Constraints) in Core?
15:32:54 [AdrianP]: Gary: issue is with core; can I have an explicity cardinality constraint in core
15:33:14 [sandro]: kifer: f-logic has it.
15:34:30 [AxelPolleres]: Answer set programming has it as well.
15:35:00 [AdrianP]: Harold: f-logic and RuleML have special syntactic constructs to distinguish cardinality
15:35:24 [AdrianP]: Michael: SWRL has cardinality constraints
15:35:35 [sandro]: mk: SWRL and Flora-2 have cardinality constraints.
15:35:46 [AxelPolleres]: OWL implies equalities, doesn't have card constraints.
15:36:45 [sandro]: jos: at-most-2 cardinality gives you disjunction. at-most-1 cardinality adds equality.
15:38:03 [AdrianP]: Harold: integrity constraints could be introduced and used to define cardinality constraints
15:38:07 [sandro]: mk: Integrity Constraints require the Closed World Assumption.
15:38:53 [sandro]: mk: equating two months is a problem....
15:38:58 [sandro]: s/months/mothers/
15:39:23 [AdrianP]: Harold: integrity constrain semantics instead of open equality semantics could be introduced
15:40:54 [AdrianP]: Chris: needs a closed assumption
15:41:23 [AdrianP]: Harold: person who uses RIF makes a closed world assumption
15:42:02 [AdrianP]: Gary: my original proposal was to have the syntax but its just like a comment
15:42:15 [AdrianP]: Gary: in BLD and PRD the semantics is then defined
15:42:37 [DaveReynolds]: But different surely.
15:42:49 [AdrianP]: Chris: this is option 1
15:44:38 [AdrianP]: Michael: interoperability?
15:44:45 [Harold]: s/person who uses RIF makes/person who uses RIF's multiplicity="1" attribute makes/
15:44:55 [AdrianP]: Michael: would need to define what interoperabiltiy then means?
15:46:04 [AdrianP]: Chris: option 1 uses meta data, so it is meaningless / might be ignored
15:46:41 [AdrianP]: Michael: this ok, if we define interoperability accordingly
15:47:00 [AdrianP]: Chris: PRD doesn't ignore meta data?
15:48:16 [AdrianP]: Chris: option 4 does not allow you to express cardinality constraints
15:48:21 [AdrianP]: Chris: Gary wants them
15:48:33 [AdrianP]: Sandro: Gary wants type checking
15:48:37 [DaveReynolds]: But Gary you are giving it different semantics in BLD and PRD so that isn't an argument for them in Core.
15:49:34 [AdrianP]: Michael: semantics of cardinality in Core is different from the semantics in PRD
15:50:21 [DaveReynolds]: -1 for logical constraints in core, 0 for closed world integrity constraints (potentially useful, huge work, don't see how to get it done in remaining time)
15:50:37 [sandro]: mk: It's a good idea, but I'm worried it will be musused.
15:51:34 [AxelPolleres]: -1 (it seems that with a decent semantics for modify, there can still be a PRD (sub?)dialect based on Core without)
15:52:18 [AxelPolleres]: (... i.e. modify meaning delete all existing values and assert new value)
15:52:50 [sandro]: Chris: This would not be the first feature we abandoned.
15:52:58 [sandro]: (first useful features)
15:53:48 [sandro]: chris: It seems we're leaning toward option 4.
15:56:50 [Zakim]: -DaveReynolds
15:57:13 [Zakim]: -Meeting_Room
15:57:15 [Zakim]: SW_RIF(F2F)8:00AM has ended
15:57:17 [Zakim]: Attendees were DaveReynolds, csma, josb, MichaelKifer, AxelPolleres, cke, johnHall, AdrianP, Harold, Gary, sandro, ChrisW, Meeting_Room
16:44:51 [johnhall]: johnhall has joined #rif
17:01:47 [Zakim]: Zakim has left #rif
17:25:31 [johnhall]: johnhall has joined #rif
17:34:35 [DaveReynolds]: DaveReynolds has joined #rif
17:37:51 [josb]: josb has joined #rif
17:39:12 [MichaelKifer]: MichaelKifer has joined #rif
17:39:47 [AxelPolleres]: AxelPolleres has joined #rif
17:40:01 [AxelPolleres]: dave, are you on the phone?
17:40:05 [ChrisW]: ChrisW has joined #rif
17:40:12 [ChrisW]: zakim, who is here?
17:40:15 [AdrianP]: AdrianP has joined #rif
17:40:29 [DaveReynolds]: Yes but I can't hear anything
17:40:29 [Zakim]: Zakim has joined #rif
17:40:33 [ChrisW]: zakim, this is rif
17:40:33 [Zakim]: ok, ChrisW; that matches SW_RIF(F2F)8:00AM
17:40:40 [ChrisW]: zakim, who is on the phone?
17:40:40 [Zakim]: On the phone I see +44.145.441.aaaa
17:40:48 [ChrisW]: rrsagent, make minutes
17:40:48 [RRSAgent]: I have made the request to generate http://www.w3.org/2009/04/15-rif-minutes.html ChrisW
17:40:53 [cke]: cke has joined #rif
17:40:57 [AxelPolleres]: we are dialing in
17:41:27 [AxelPolleres]: AxelPolleres has changed the topic to: RIF 13th F2F Meeting, Cambridge MA, Agenda http://www.w3.org/2005/rules/wiki/F2F13
17:42:22 [Harold]: Harold has joined #rif
17:42:32 [AxelPolleres]: scribe: Axel Polleres
17:42:40 [AxelPolleres]: scribenick: AxelPolleres
17:42:46 [AxelPolleres]: topic: Issue-81
17:42:58 [josb]: http://lists.w3.org/Archives/Public/public-rif-wg/2009Mar/0140.html
17:43:12 [AxelPolleres]: http://www.w3.org/2005/rules/wg/track/issues/81
17:43:30 [josb]: http://lists.w3.org/Archives/Public/public-rif-wg/2009Mar/0140.html
17:43:33 [csma]: csma has joined #rif
17:43:38 [josb]: http://lists.w3.org/Archives/Public/public-rif-wg/2009Mar/0140.html
17:43:57 [AxelPolleres]: jos: let's talk about that email first (coreify OWL2RL combinations)
17:44:00 [Zakim]: +W3C
17:44:39 [AxelPolleres]: we need equality for OWL RL, outside Core
17:44:47 [sandro]: 1 == too bad, RL isn't in Core
17:44:56 [sandro]: 2 == pick an equality-free embedding
17:44:56 [AxelPolleres]: first option, not possible in Core
17:45:12 [sandro]: 3 == general embedding into BLD, then pick a subset in Core (== 1+2)
17:45:18 [AxelPolleres]: ... second option equality free subset
17:45:32 [sandro]: 4 == Add embedding of equality. (Axiomatizing equality.)
17:45:32 [AxelPolleres]: ... third option, embedding in BLD
17:46:05 [AxelPolleres]: ...fourth, add equality axioms in core
17:46:20 [AxelPolleres]: ... i.e. axiomatize equality.
17:47:19 [AxelPolleres]: sandro: I like 4, if there is a way to use rif:"=" i.e. BLD's equality here.
17:47:21 [StellaMitchell]: StellaMitchell has joined #rif
17:48:00 [AxelPolleres]: csma: RIF can be expressed in BLD, but not in Core, what is the negative impact of that?
17:48:14 [AxelPolleres]: chrisW: Core won't do OWL RL.
17:48:32 [DaveReynolds]: Depends what you mean by "do OWL RL" - them embedding is different from the direct OWL 2 RL rule implementation which does fit in Core.
17:48:41 [DaveReynolds]: s/them/the/
17:48:51 [AxelPolleres]: sandro: whatever we pcik we should be able to explain the different choices.
17:49:17 [AxelPolleres]: ... I am for 4) because it gives us OWL RL in Core.
17:50:07 [AxelPolleres]: jos: you can implement it more efficient.
17:50:13 [sandro]: sandro: This is a proof-of-concept, so performance is not an issue.
17:51:06 [AxelPolleres]: csma: does that open the possibility that a BLD doc uses rif equality that works together with the core axiomatization
17:51:32 [AxelPolleres]: ... ? We have to make an informed decision in that respect.
17:51:34 [GaryHallmark]: GaryHallmark has joined #rif
17:52:21 [sandro]: axel: maybe use owl:sameAs.
17:52:50 [AxelPolleres]: Axel: Can owl:sameAs be used for the axiomaization?
17:53:24 [AxelPolleres]: csma: What is the drawback of only providing an embedding in BLD?
17:53:55 [DaveReynolds]: My preference would be 1 and add a comment to point out options 2 & 4 but not exhibit them.
17:54:19 [AxelPolleres]: jos... explains the different options again.
17:54:39 [sandro]: DaveReynolds, do you think the axiomatizing equality is a problem?
17:55:19 [DaveReynolds]: Sandro -It seems like it would like to a large unwieldy rule set, it would be more an academic exercise that something people would really use. Perhaps I'm misunderstanding.
17:55:33 [AxelPolleres]: sandro: I like option 4 more for political and marketing than for technical reasons.
17:55:51 [DaveReynolds]: q+
17:56:00 [AxelPolleres]: ... because we can say we support OWL RL with RIF for free.
17:56:02 [josb]: indeed, the ruleset is going to be very unwieldy
17:56:14 [josb]: esp if we go for b, c, or d
17:56:27 [AxelPolleres]: csma: problem I have with 4 is that I don't see PRD here.
17:56:45 [DaveReynolds]: ack me
17:56:52 [sandro]: sandro: I want to be able to say "Anyone who has RIF, get OWL-RL for free".
17:57:28 [AxelPolleres]: dave: in response to sandro: We have shown that we can implement OWL RL, but we can't say that we have OWL RL per se.
17:59:41 [AxelPolleres]: jos: I'd prefer a)
18:00:00 [AxelPolleres]: ... there are now a bunch of unsafe rules in the ruleset.
18:00:19 [AxelPolleres]: ... I don't see the benefit of having OWL2RL in BLD.
18:00:49 [AxelPolleres]: ... we can make some explanation but shouldn't tweak the ruleset at this point.
18:00:59 [AxelPolleres]: csma: quick poll?
18:01:24 [AxelPolleres]: chris: OWL2RL is in core, but combinations with Rules is in BLD.
18:01:50 [sandro]: chris: OWL 2 RL is in Core (reasoning over OWL alone), but OWL 2 RL in combination with Core Rules puts you into BLD.
18:02:03 [sandro]: Sandro: ah. :-)
18:02:38 [DaveReynolds]: prefer a
18:02:59 [AxelPolleres]: csma: who prefers a)?
18:03:14 [AxelPolleres]: ... jos and chris
18:03:20 [AxelPolleres]: who prefers d)?
18:03:25 [AxelPolleres]: sandro, axel
18:04:15 [AxelPolleres]: Sandro: I'd prefer a) with an explanaiton how to get to d) and what the implications are.
18:04:37 [sandro]: sandro: So go with (A), but provide some text spelling out how to do (D) ....
18:04:55 [josb]: http://lists.w3.org/Archives/Public/public-rif-wg/2009Mar/0140.html
18:05:55 [AxelPolleres]: PROPOSED: We go for solution a) in http://lists.w3.org/Archives/Public/public-rif-wg/2009Mar/0140.html plus additionally pointing out the path to d) and what the implications were in a non-normative subsection.
18:05:57 [sandro]: "embedding in support of combination"
18:06:08 [sandro]: +1
18:06:36 [ChrisW]: PROPOSED: For OWL-2 RL embedding of combinations, provide a (informative) embedding in BLD, pointing out that one can axiomatize equality for specific predicates in Core
18:07:34 [ChrisW]: PROPOSED: For OWL-2 RL embedding of combinations, provide a (informative) embedding in BLD, pointing out that one can axiomatize equality for predicates in Core
18:07:47 [sandro]: +1
18:07:52 [josb]: +1
18:07:56 [ChrisW]: +6
18:07:59 [Harold]: +1
18:07:59 [DaveReynolds]: +1
18:08:01 [AxelPolleres]: Axel: can we use owl:sameAs in that axiomatization?
18:08:06 [MichaelKifer]: 0
18:08:20 [AxelPolleres]: +1 given that owl:sameAs is used :-)
18:08:34 [GaryHallmark]: +0
18:08:41 [AdrianP]: 0
18:08:49 [johnhall]: +1
18:09:07 [ChrisW]: RESOLVED: For OWL-2 RL embedding of combinations, provide a (informative) embedding in BLD, pointing out that one can axiomatize equality for predicates in Core
18:09:32 [ChrisW]: action: implement resolution on embedding of OWL-2 RL embedding of combinations
18:09:33 [trackbot]: Sorry, couldn't find user - implement
18:09:49 [ChrisW]: action: axel to review owl-2 rl embedding of combinations
18:09:50 [trackbot]: Created ACTION-733 - Review owl-2 rl embedding of combinations [on Axel Polleres - due 2009-04-22].
18:10:04 [sandro]: subtopic: OWL datatypes, OWL RL datatypes
18:10:04 [ChrisW]: action: josb implement resolution on embedding of OWL-2 RL embedding of combinations
18:10:04 [trackbot]: Created ACTION-734 - Implement resolution on embedding of OWL-2 RL embedding of combinations [on Jos de Bruijn - due 2009-04-22].
18:10:47 [AxelPolleres]: csma: where are we w.r.t. issue-81?
18:10:54 [sandro]: issue-81?
18:10:54 [trackbot]: ISSUE-81 -- Support for additional OWL-RL datatype -- OPEN
18:10:54 [trackbot]: http://www.w3.org/2005/rules/wg/track/issues/81
18:10:55 [AxelPolleres]: http://www.w3.org/2005/rules/wg/track/issues/81
18:11:21 [sandro]: OWL RL Datatypes: http://www.w3.org/2007/OWL/wiki/Profiles#Entities_3
18:12:07 [DaveReynolds]: http://www.w3.org/2005/rules/wiki/OWLRL#Datatypes_supported is supposed to up to date wrt to current DTB
18:12:22 [DaveReynolds]: OWL 2 RL types changed since the issues page was created
18:13:10 [csma]: ACTION: to axel to add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary in DTB
18:13:10 [trackbot]: Sorry, couldn't find user - to
18:13:20 [MichaelKifer]: MichaelKifer has left #rif
18:13:31 [MichaelKifer]: MichaelKifer has joined #rif
18:13:44 [csma]: ACTION: Axel to add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary in DTB
18:13:44 [trackbot]: Created ACTION-735 - Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary in DTB [on Axel Polleres - due 2009-04-22].
18:14:52 [sandro]: owl:realPlus is gone now.
18:15:11 [DaveReynolds]: http://www.w3.org/2005/rules/wiki/OWLRL#Datatypes_supported is supposed to up to date wrt to current DTB and updated OWL 2
18:15:57 [DaveReynolds]: s/2/2 RL/
18:18:17 [AxelPolleres]: ACTION: Axel to add owl:real in DTB
18:18:17 [trackbot]: Created ACTION-736 - Add owl:real in DTB [on Axel Polleres - due 2009-04-22].
18:18:26 [josb]: http://www.w3.org/2007/OWL/wiki/Syntax#Datatype_Maps
18:19:56 [AxelPolleres]: datatypes to be added... cf. http://www.w3.org/2005/rules/wiki/DataTypes
18:25:13 [AxelPolleres]: chrisw: proposal to support subtypes of integer, subtypes of string, but no separate predicates such as guards for these.
18:26:06 [AxelPolleres]: gary: by isliteraloftype we don't have to do anything.
18:27:42 [AxelPolleres]: csma: what about datetimestamp?
18:28:13 [AxelPolleres]: chrisw: anyone argues for any other support or has objections against those?
18:28:37 [AxelPolleres]: csma: what about owl:rational?
18:28:45 [AxelPolleres]: jos: at risk in the current owl spec.
18:29:14 [DaveReynolds]: q+ re: owl:rational
18:31:09 [AxelPolleres]: axel: what about p(x) :- x*x=2.
18:31:24 [AxelPolleres]: jos: no problem since multiplicaiton not defined for real.
18:31:43 [AxelPolleres]: dave: problem with arithmetics
18:32:10 [AxelPolleres]: chrisw: numeric built-ins on owl:reals would create problems.
18:32:35 [DaveReynolds]: dave - owl:rational arithmetic and promotion to decimal/double *could* be support, my point was that this would be real work to define
18:32:47 [DaveReynolds]: s/support/supported/
18:33:19 [AxelPolleres]: ... real and rational have no built-in support other than guards.
18:34:19 [AxelPolleres]: jos: real is trivial.
18:34:31 [AxelPolleres]: ... rational is a superset of decimal
18:34:40 [sandro]: The value space of owl:rational is the set of all rational numbers. It is a subset of the value space of owl:real, and it contains the value space of xsd:decimal (and thus of all xsd: numeric datatypes listed above as well).
18:35:03 [Zakim]: -DaveReynolds
18:35:10 [sandro]: The owl:rational datatype supports lexical forms defined by the following grammar ... numerator '/' denominator
18:35:23 [AdrianP]: which concrete rule engines support rationals - is there any need for that datatype?
18:35:23 [csma]: PROPOSED: Add the following primitive data types, without guard predicates or other builtins for subtypes of xs:string and xs:integer: owl:rational, xsd:nonPositiveInteger, xsd:positiveInteger, xsd:negativeInteger, xsd:long, xsd:int, xsd:short, xsd:byte, xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort, xsd:unsignedByte, xsd:float, xsd:normalizedString, xsd:token, xsd:language,...
18:35:25 [csma]: ...xsd:Name, xsd:NCName, xsd:NMTOKEN, xsd:boolean, xsd:datetimestamp
18:35:28 [sandro]: http://www.w3.org/2007/OWL/wiki/Syntax#Real_Numbers.2C_Decimal_Numbers.2C_and_Integers
18:35:38 [AxelPolleres]: ... so some rational values of are in the scope of the builtins (those which happen to be decimals), others no
18:36:04 [Zakim]: +DaveReynolds
18:36:53 [csma]: PROPOSED: Add the following primitive data types, without builtins (other than guard predicates) for subtypes of xs:string and xs:integer: owl:rational, xsd:nonPositiveInteger, xsd:positiveInteger, xsd:negativeInteger, xsd:long, xsd:int, xsd:short, xsd:byte, xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort, xsd:unsignedByte, xsd:float, xsd:normalizedString, xsd:token, xsd:language,...
18:36:55 [csma]: ...xsd:Name, xsd:NCName, xsd:NMTOKEN, xsd:boolean, xsd:datetimestamp
18:37:53 [csma]: PROPOSED: Add the following primitive data types, without builtins (other than guard predicates) for subtypes of xs:string and xs:integer: xsd:nonPositiveInteger, xsd:positiveInteger, xsd:negativeInteger, xsd:long, xsd:int, xsd:short, xsd:byte, xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort, xsd:unsignedByte, xsd:float, xsd:normalizedString, xsd:token, xsd:language, xsd:Name, xsd:NCName, xsd
18:37:55 [csma]: :NMTOKEN, xsd:boolean, xsd:datetimestamp
18:38:11 [sandro]: We understand these to be ALL OWL datatypes except owl:rational.
18:38:49 [sandro]: We understand this will make RIF support all the same datatypes as OWL, except owl:rational.
18:39:11 [csma]: PROPOSED: Add the following primitive data types, without builtins (other than guard predicates) for subtypes of xs:string and xs:integer: xsd:nonPositiveInteger, xsd:positiveInteger, xsd:negativeInteger, xsd:long, xsd:int, xsd:short, xsd:byte, xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort, xsd:unsignedByte, xsd:float, xsd:normalizedString, xsd:token, xsd:language, xsd:Name, xsd:NCName, xsd
18:39:13 [csma]: :NMTOKEN, xsd:boolean, xsd:datetimestamp; with thiese additions, RIF has all OWL datatypes except owl:rational
18:39:19 [AxelPolleres]: jos: realizing the problems with built-ins, I am hesitant about owl:rational
18:39:37 [AxelPolleres]: chrisw: shall we approach owl with commenting on why we don't like owl:rational?
18:41:24 [Michael_Kifer]: Michael_Kifer has joined #rif
18:41:45 [ChrisW]: PROPOSED: support all OWL datatypes in RIF except owl:rational (to be discussed further)
18:42:16 [sandro]: +1
18:42:27 [DaveReynolds]: This this proposal include adding the builtins for boolean, datetimestamp?
18:42:29 [josb]: +1
18:42:31 [DaveReynolds]: s/This/Does/
18:42:35 [ChrisW]: yes, DaveReynolds
18:42:37 [Harold]: +1
18:42:40 [AxelPolleres]: 0 still don't fancy owl:real
18:42:41 [DaveReynolds]: 0
18:42:42 [sandro]: we're not deciding about builtins yet, DaveReynolds
18:42:44 [AdrianP]: +1
18:42:52 [MichaelKifer]: +1
18:42:59 [johnhall]: =1
18:43:04 [ChrisW]: +1
18:43:19 [AxelPolleres]: s/0 still don't fancy owl:real/+1/
18:44:14 [ChrisW]: RESOLVED: support all OWL datatypes in RIF except owl:rational (to be discussed further)
18:44:42 [sandro]: PROPOSED: Remove owl:realPlus since OWL removed it.
18:44:46 [ChrisW]: +1
18:44:49 [sandro]: +1
18:44:52 [DaveReynolds]: +1
18:44:52 [AdrianP]: +1
18:44:54 [josb]: +q1
18:44:56 [josb]: +1
18:45:01 [Harold]: +1
18:45:04 [DaveReynolds]: -q
18:45:04 [johnhall]: +1
18:45:09 [csma]: ack dave
18:45:10 [sandro]: queue=
18:45:12 [csma]: ack 1
18:45:21 [sandro]: RESOLVED: Remove owl:realPlus since OWL removed it.
18:45:49 [josb]: http://www.w3.org/TR/xmlschema11-2/#dateTimeStamp
18:46:25 [AxelPolleres]: axel: datetimestamp is a subtype of datetime, so all builtins apply.
18:47:06 [sandro]: jos: We already have all the builtins for dateTimeStamp, since it's a subtype of dateTime.
18:47:44 [AxelPolleres]: jos: boolean has less-than, equal, ...
18:48:51 [AxelPolleres]: sandro: overlap of fn:true, fn:false with rif:true rif:false is awkward.
18:49:40 [AxelPolleres]: q+ to ask: What about casting?
18:49:42 [sandro]: (where rif:true is really an empty-OR)
18:52:17 [AxelPolleres]: axel: we can cast boolean to integer.
18:54:15 [AxelPolleres]: ... I'd prefer all or none of the built-ins for boolean.
18:54:18 [sandro]: Sandro: the reason to have builtins to boolean is to support data out there using xs:boolean
18:54:35 [AxelPolleres]: adrian: prefer to have less than more.
18:54:36 [sandro]: Chris: the reason to not have xs:boolean is confusing vs RIF predications
18:54:47 [AxelPolleres]: sandro: I'd prefer all.
18:55:35 [sandro]: Gary: People are going to complain about rif predicates not just being functions that return true.
18:55:39 [sandro]: sandro: yeah...
18:55:46 [csma]: PROPOSED: include all the builtins for xs:boolean per F&O
18:55:47 [ChrisW]: +true
18:55:56 [sandro]: +0.5
18:56:04 [csma]: fn:not(fn:false) (maybe?)
18:56:18 [GaryHallmark]: +1
18:56:20 [sandro]: where does truth lie
18:56:21 [DaveReynolds]: +1
18:56:22 [AxelPolleres]: +xs:integer("true"^^xs:boolean)
18:56:24 [MichaelKifer]: -0.2
18:56:28 [josb]: +And()
18:56:33 [AdrianP]: 0
18:56:43 [GaryHallmark]: +money
18:56:49 [josb]: -Or()
18:57:02 [Harold]: +1
18:57:07 [csma]: RESOLVED:include all the builtins for xs:boolean per F&O
18:57:27 [AxelPolleres]: ACTION: axel to include all the builtins for xs:boolean per F&O
18:57:27 [trackbot]: Created ACTION-737 - Include all the builtins for xs:boolean per F&O [on Axel Polleres - due 2009-04-22].
18:57:27 [ChrisW]: action: axel to add all boolean builtins
18:57:28 [trackbot]: Created ACTION-738 - Add all boolean builtins [on Axel Polleres - due 2009-04-22].
18:59:09 [ChrisW]: action: axel to add xs:float to numeric builtins
18:59:09 [trackbot]: Created ACTION-739 - Add xs:float to numeric builtins [on Axel Polleres - due 2009-04-22].
19:03:10 [AxelPolleres]: http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#casting-from-primitive-to-primitive
19:07:35 [ChrisW]: action: axel to accomodate casting functions in a well defined manner
19:07:35 [trackbot]: Created ACTION-740 - Accomodate casting functions in a well defined manner [on Axel Polleres - due 2009-04-22].
19:07:57 [sandro]: subtopic: owl:rational
19:08:02 [sandro]: sandro: anyone want to argue for it.
19:08:24 [AxelPolleres]: csma: who wants owl:rational?
19:09:13 [AxelPolleres]: PROPOSED: we do not include owl:rational closing issue-81
19:10:22 [sandro]: why not have it?
19:10:29 [sandro]: Gary: Because implementing it is a pain
19:10:56 [AdrianP]: +1
19:10:59 [AxelPolleres]: +1
19:11:03 [DaveReynolds]: +1
19:11:06 [sandro]: sandro: but you could specify small enough precision requirements (so you can just use double)....?
19:11:06 [johnhall]: +1
19:11:22 [AxelPolleres]: kifer: this wouldn't be the most difficult thing to do.
19:11:51 [sandro]: gary: That's not what users will be expecting. [[ They'll assume 1/3 + 1/3 == 2/3 not 0.6666666666666667 ]]
19:12:26 [sandro]: +0
19:12:41 [AxelPolleres]: jos: arithmetics only defined for a subset, that seems to be problematic and unintuitive.
19:12:51 [csma]: RESOLVED: : we do not include owl:rational (closing issue-81)
19:13:04 [ChrisW]: action: Chris to close issue-81
19:13:04 [trackbot]: Created ACTION-741 - Close issue-81 [on Christopher Welty - due 2009-04-22].
19:13:08 [ChrisW]: rrsagent, pointer?
19:13:08 [RRSAgent]: See http://www.w3.org/2009/04/15-rif-irc#T19-13-08
19:13:36 [ChrisW]: action: chris to respond to OWL WG public comment response
19:13:36 [trackbot]: Created ACTION-742 - Respond to OWL WG public comment response [on Christopher Welty - due 2009-04-22].
19:15:33 [sandro]: axel: x times x ....
19:16:07 [sandro]: chris: But the type signature of times is what it is, eg decimal x decimal -> decimal
19:17:11 [AxelPolleres]: p(X) :- X*X = 2.
19:17:11 [AxelPolleres]: q(Y) :- X*X = Y, p(X).
19:17:12 [AxelPolleres]: would NOT entail q(2).
19:17:19 [sandro]: http://www.w3.org/2007/OWL/wiki/Profiles#Entities_3
19:18:37 [AxelPolleres]: jos:it looks like there is an error in the owl2 spec.
19:18:56 [AxelPolleres]: ... rdfs:Literal is not a datatype according to the spec.
19:18:57 [sandro]: "The built-in datatype rdfs:Literal denotes any set that contains the union of the value spaces of all datatypes in the datatype map. "
19:20:20 [sandro]: jos: There is no way to access the irrationals.
19:21:02 [sandro]: chris: Axel, your strange lack-of-entailment exists, regardless of owl:real.
19:21:09 [AxelPolleres]: axel: having a datatype real "suggests: that the example would work
19:21:29 [AxelPolleres]: s/suggests:/suggests"/
19:21:39 [sandro]: sandro: but the presence of owl:real makes folks more likely to be bothered by it.
19:22:23 [AxelPolleres]: chrisw: break now and move to extensibility or ISSUES-95 ISSUES-95 then.
19:23:03 [AxelPolleres]: s/extensibility/ISSUE-57/
19:23:05 [AxelPolleres]: ... I like to close on the issues after the break.
19:23:31 [AxelPolleres]: ... let's do 5 more minutes on extensibility.
19:24:02 [AxelPolleres]: sandro: cool mechanism for extensibility would be great but not manageable in time. so let's do something simple.
19:25:14 [AxelPolleres]: ... e.g. PRD rewriteable to Core should be interchangeable.
19:25:50 [AxelPolleres]: csma: I am sad about the non-interoperability.
19:26:54 [sandro]: csma: this means: drop bounded quantifiers in PRD
19:27:24 [AxelPolleres]: ... consequence for PRD: We shall remove bounded quantifiers in this version of PRD.
19:27:37 [sandro]: csma: Everything that CAN be written in Core, MUST be expressed in Core.
19:27:47 [sandro]: gary: then revisit no-nested-function-symbols.
19:28:04 [AxelPolleres]: gary: nested function symbols also need to be revisited.
19:28:16 [AxelPolleres]: jos: does that also mean you remove assert?
19:28:48 [sandro]: csma: Assert will not be used if the ONLY action is Assert, but if there are RETRACT, NEW, MODIFY, then.
19:28:55 [sandro]: gary: conjuncts in the head in Core>
19:28:58 [DaveReynolds]: Core currently does have nested function symbols in the body
19:29:03 [sandro]: harold: yes, it was removed.
19:29:17 [sandro]: Gary: Put nested functions and conjuncts in head back into Core.
19:29:23 [DaveReynolds]: s/function symbols/external functions/
19:30:27 [sandro]: mk: I think it was a mistake to remove conjunction in the head.
19:30:43 [sandro]: mk: (that is -- we didn't mean to remove it. it's just a typo.)
19:30:48 [DaveReynolds]: We did get rid of disjunction at one point but the wg voted to put it back in :-(
19:31:13 [AxelPolleres]: BREAK
19:32:29 [AxelPolleres]: no BREAK...
19:32:50 [AxelPolleres]: chrisw: what was the rationale for not having conjunction in heads in Core?
19:33:09 [AxelPolleres]: dave: it wasn't in the minimum set we started with and it wasn't claimed in by anybody.
19:33:45 [Zakim]: -DaveReynolds
19:34:09 [Zakim]: -W3C
19:34:11 [Zakim]: SW_RIF(F2F)8:00AM has ended
19:34:12 [Zakim]: Attendees were +44.145.441.aaaa, DaveReynolds, W3C
20:07:43 [sandro]: DaveReynolds, do you want us to get back on the phone?
20:07:53 [DaveReynolds]: Yes please
20:07:58 [DaveReynolds]: Just about to dial in
20:08:07 [johnhall]: CW: Discussed in break - ground lists, safe lists (variable only if bound oustdie list), built-ins
20:08:30 [johnhall]: CW: preferences?
20:08:33 [sandro]: chris: 2 is a little more expressive than 1
20:08:34 [johnhall]: Jos: 1
20:08:50 [johnhall]: Jos: no lists in Core
20:09:05 [johnhall]: csma: 4th option is no list at all
20:09:15 [Zakim]: SW_RIF(F2F)8:00AM has now started
20:09:22 [Zakim]: +DaveReynolds
20:09:41 [johnhall]: Michael: ground lists strightforward
20:09:57 [johnhall]: Michael: safe lists more difficult
20:10:03 [sandro]: jos: for 2, you have to support constructive terms in your engine ... it's basically the same as function terms.
20:10:57 [johnhall]: csma: argument - inorder to define built-ins on core, you need the ground lists
20:11:06 [Harold]: Harold has joined #rif
20:11:09 [sandro]: DaveReynolds?
20:11:18 [csma]: (and that's builtins that are useful, not ground lists)
20:11:33 [johnhall]: Michael: how hard to add safe lists for Datalog engines?
20:11:44 [johnhall]: CW: preferences?
20:11:45 [Zakim]: +W3C
20:12:07 [ChrisW]: zakim, who is on the phone?
20:12:07 [Zakim]: On the phone I see DaveReynolds, W3C
20:12:20 [johnhall]: Miachael: how hard to implement lists with variables?
20:12:41 [johnhall]: DR: variable? Prolog unbound term?
20:12:48 [johnhall]: DR: would be hard
20:13:00 [johnhall]: GH: if bound?
20:13:54 [johnhall]: cke: differenes between 1 and 2 is for 1 can do staic analysis, 2 dynamic in execution
20:14:38 [DaveReynolds]: Unification is not that hard so long as the asserted data is variable-free, just pattern matching.
20:14:55 [johnhall]: Gary:go back to charter - we should have lists
20:15:08 [johnhall]: Gary: should be in core
20:15:38 [johnhall]: Michael: Core could do 1, PRD could do 2 as an extension
20:15:53 [DaveReynolds]: Could you post what 1, 2 refer to?
20:15:56 [csma]: (1 is: "ground lists + builtins in Core; 2: is Core has safe lists = variables allowed in lists only if they are bound outside + builtins)
20:16:32 [johnhall]: 1 is ground lists, 2 is safe lists
20:16:32 [csma]: (that's written on the wall)
20:16:52 [johnhall]: But Dave can't see the wall
20:16:58 [csma]: 5there is also 3: no lits in Core°
20:17:05 [DaveReynolds]: Lists without constructing them sound pretty useless.
20:17:43 [DaveReynolds]: Stable position would be to forgo E-S safe, stick to simple safety, allow non-termination, have list constructor builtins
20:17:56 [johnhall]: Michael: can define built ins to construct
20:18:03 [DaveReynolds]: Second stable position would be no-non-termination and so no useful list constructors.
20:18:22 [johnhall]: Axel: safeness?
20:18:33 [johnhall]: Michael: out of the window
20:19:32 [johnhall]: Michael: need const, then can construct infinitely long list
20:19:50 [johnhall]: Gary: not saying Core has to be finite
20:20:14 [sandro]: gary: safeness is about bottom-up evaluation, not finite operation (termination)
20:21:35 [johnhall]: Dave: is purpose of safety in core to support bottom-up evaluation, or termination for Datalog engines?
20:22:20 [AxelPolleres]: dave: you meant top-down, not bottom, up... yes?
20:22:30 [sandro]: dave: either have recursive structures or have finite-operation. pick one camp or the other.
20:22:44 [DaveReynolds]: Axel - I mean forward chaining
20:22:44 [AxelPolleres]: datalog = bottom-up
20:22:46 [sandro]: I translate that to "forward-chaining".
20:22:59 [johnhall]: Michael: proposal was to have first, tail, const
20:23:08 [sandro]: s/const/cons/
20:23:14 [johnhall]: cke: append?
20:23:17 [josb]: yes, standard safeness we have now is for bottom-up evaluation
20:23:28 [DaveReynolds]: If we have cons then we should drop E-S safe
20:23:31 [johnhall]: Michael: for PRD need more
20:24:46 [johnhall]: ChrisW: ground list plus first, rest, cons?
20:24:50 [AxelPolleres]: Dave, I don't like that... we would have the effect that strongly safe rulesets which use lists are probably useless in practical.
20:24:53 [johnhall]: cke: why cons?
20:25:07 [johnhall]: Michael: is the basic one for others
20:25:17 [AxelPolleres]: I could just view cons as yet another built-in, that's it.
20:25:26 [DaveReynolds]: Axel - exactly, strongly safe means that rulesets with lists are useless. You can have lists. or strongly safe but not both.
20:25:42 [AxelPolleres]: S-E- safe still has its merits.
20:26:06 [johnhall]: Gary: look at Ch 15 Xpath
20:26:12 [AxelPolleres]: it appears that, together with some built-ins, it moght still make sense.
20:26:27 [csma]: http://www.w3.org/TR/xpath-functions/#sequence-functions
20:26:29 [sandro]: Chris: Ground lists, plut first/rest/constructors ?
20:26:36 [johnhall]: ChrisW: doe we have consensus on ground + first, rest, cons?
20:27:28 [johnhall]: Axel: if you require safe rules, others cannot be built from cons
20:28:20 [sandro]: chris: These are immutable lists.
20:28:45 [johnhall]: Harold: in ground list can replace elements
20:29:52 [AxelPolleres]: emulating other list built-ins with cons needs cons in rule heads, or at least S-E-unsafe use of cons().
20:29:55 [sandro]: cons == prepend
20:30:07 [sandro]: cons == make new list with added element.
20:30:24 [johnhall]: ChrisW: close soon. What do we agree on?
20:30:29 [Harold]: ?x = List(a b c d) AND ?y = func:replace(2 beta ?x) will bind ?y to List(a beta c d)
20:30:38 [johnhall]: Gary: ground lists with Xpath operators
20:30:56 [johnhall]: csma: what perdicates?
20:30:56 [sandro]: PROPOSED: Core will have Ground Lists with basic XPath "Sequence" operators.
20:31:05 [johnhall]: Gary: empty and exists
20:31:18 [DaveReynolds]: -1 Xpath sequences are not nested, they are flat
20:31:46 [sandro]: PROPOSED: Core will have immutable Ground Lists (no variables stored inside the list) with basic XPath "Sequence" operators.
20:31:47 [AxelPolleres]: member
20:31:47 [AxelPolleres]: first
20:31:47 [AxelPolleres]: last
20:31:47 [AxelPolleres]: length
20:32:35 [sandro]: PROPOSED: Core will have immutable Ground Lists (no variables stored inside the list) with builtins paralleling the XPath "Sequence" functions (but this isn't a real XPath sequence, since it can be nested, etc)
20:34:26 [johnhall]: csma: see Changhai�s wish list (slides)
20:35:04 [johnhall]: csma: some Xpath are not relevant
20:35:10 [sandro]: PROPOSED: Core will have immutable Ground Lists (no variables stored inside the list) with builtins generally paralleling the XPath "Sequence" functions (but this isn't a real XPath sequence, since it can be nested, etc)
20:35:16 [DaveReynolds]: Is the proposal to remove strong safety at the same time?
20:35:31 [sandro]: PROPOSED: Core will have immutable Ground Lists (no variables stored inside the list) with builtins generally paralleling the XPath "Sequence" functions (but this isn't a real XPath sequence, since it can be nested, etc). (Actual builtins to be settled in the future, soon)
20:36:46 [sandro]: axel: Sure, if you're E-S-Safe, you can't do much with lists. That's okay.
20:36:47 [johnhall]: ChrisW: safety is not a requirement in Core
20:38:18 [sandro]: Gary: Lots of arithmetic violates strong safeness again.
20:38:49 [sandro]: Axel: but if we get rid of strong safeness, then many answer set programming systems wont be able to support Core.
20:38:52 [johnhall]: Axel: Datalog engines are not fully covered
20:39:06 [sandro]: axel: s-models, clasp,
20:39:38 [johnhall]: ChrisW: we have still not resolved safeness
20:40:00 [sandro]: PROPOSED: Core will have immutable Ground Lists (no variables stored inside the list) with builtins generally paralleling the XPath "Sequence" functions (but this isn't a real XPath sequence, since it can be nested, etc). (Actual builtins to be settled in the future, soon) (If we have strong safeness in Core, then this stuff will be mostly useless in Core.)
20:40:15 [johnhall]: ChrisW: BLD does not require safeness
20:40:38 [DaveReynolds]: OK
20:40:57 [johnhall]: ChrisW: can we save safeness until tomorrow, and decide on lists now?
20:40:59 [AdrianP]: +1
20:41:02 [GaryHallmark]: +1
20:41:07 [sandro]: +1
20:41:21 [DaveReynolds]: +1
20:41:23 [josb]: 0
20:41:26 [AxelPolleres]: 0
20:41:30 [cke]: +1
20:41:39 [Harold]: +1
20:41:43 [johnhall]: +1
20:41:45 [ChrisW]: 0
20:41:48 [MichaelKifer]: +1
20:41:53 [sandro]: RESOLVED: Core will have immutable Ground Lists (no variables stored inside the list) with builtins generally paralleling the XPath "Sequence" functions (but this isn't a real XPath sequence, since it can be nested, etc). (Actual builtins to be settled in the future, soon) (If we have strong safeness in Core, then this stuff will be mostly useless in Core.)
20:42:03 [sandro]: issue-94?
20:42:03 [trackbot]: ISSUE-94 -- How to represent object fields and methods in RIF; esp. interoperability with Java OO model? -- OPEN
20:42:03 [trackbot]: http://www.w3.org/2005/rules/wg/track/issues/94
20:42:04 [johnhall]: Closes Issue 94
20:42:19 [sandro]: issue-95?
20:42:19 [trackbot]: ISSUE-95 -- Does RIF need a primitive data type (and associated builtins) for lists? -- OPEN
20:42:19 [trackbot]: http://www.w3.org/2005/rules/wg/track/issues/95
20:42:28 [AxelPolleres]: michael, the function symbols in dlv are not yet part of the standard distribution, AFAIK.
20:42:32 [johnhall]: Issue 95, not 94
20:43:26 [ChrisW]: action: gary to propose builtins for lists based on xpath sequence
20:43:26 [trackbot]: Created ACTION-743 - Propose builtins for lists based on xpath sequence [on Gary Hallmark - due 2009-04-22].
20:43:44 [sandro]: Topic: Extensibility
20:44:23 [ChrisW]: q?
20:44:35 [johnhall]: ChrisW: csma proposed - when you have something expressible in Core, you have to use Core syntax
20:44:45 [csma]: PROPOSED: We do not define an extensibility mechanism at this stage; anything that can be expressed in Core MUST be (in the XML syntax)
20:45:40 [sandro]: Jos: this would require BLD producers to axiomatize equality.
20:46:56 [johnhall]: sandro: why would this be bad?
20:47:52 [sandro]: (is this really completely unacceptable...?)
20:48:19 [johnhall]: ChrisW: identify the cases where the difference seems arbitrary?
20:48:41 [johnhall]: csma: not arbitrary - sometimes just has the same effect
20:51:11 [johnhall]: csma: purpose of common core is interoperability
20:51:44 [johnhall]: ... if some things do not have to be expressed in core, thos things are not interoperable
20:52:26 [johnhall]: Sandro: equality is a sticking point
20:53:02 [johnhall]: csma: if you can statically decide, then must be expressed in Core syntax
20:53:30 [sandro]: PROPOSED: We do not define an extensibility mechanism at this stage; any syntactic form that can in all cases be expressed in Core, without super-linear blow-up MUST be (in the XML syntax)
20:53:42 [johnhall]: ... interoperatbility is not relevant for BLD?
20:54:35 [johnhall]: Michael: why does anyone have to translate to Core - unless they want interoperability?
20:54:53 [csma]: PROPOSED: We do not define an extensibility mechanism.
20:55:08 [johnhall]: Gary: cannot legislate - too many tricky cases
20:55:45 [sandro]: PROPOSED: We do not define an extensibility mechanism at this stage; we tell PRD and BLD producers they SHOULD translate to Core any rulesets which can be translated to Core with identical semantics.
20:55:54 [johnhall]: ... say 'should' rather than 'must'
20:56:30 [AxelPolleres]: I don't understand "identical" semantics
20:56:37 [sandro]: PROPOSED: We do not define an extensibility mechanism at this stage; we tell PRD and BLD producers they SHOULD translate to Core any rulesets which can be translated to Core.
20:56:41 [johnhall]: josb: should have a mechanism to detect if rules are redundant
20:57:13 [AxelPolleres]: I don't understand "can be translated"... what kind of equivalence do we talk about here?!?
20:57:25 [sandro]: PROPOSED: We do not define an extensibility mechanism at this stage; our specs for PRD and BLD say producers they SHOULD translate to Core any rulesets which can be translated to Core, and we'll give some specific examples they should use (eg for removing Do/Assert).
20:57:31 [johnhall]: Michael: tell people to write in Core, provide algorithm for translation to dialects
20:57:38 [AxelPolleres]: q+
20:57:54 [johnhall]: csma: the algorithm was the extensibility mechanism
20:58:09 [DaveReynolds]: q+
20:59:13 [johnhall]: Axel: what does 'can be translated' mean?
20:59:26 [sandro]: PROPOSED: We do not define an extensibility mechanism at this stage. We'll provide some translations to Core (such as removing Do/Assert in some case) and tell producers they SHOULD do them.
20:59:47 [josb]: I can support this one
21:00:07 [johnhall]: DAve: by 'producers' rule set authors or translators?
21:00:21 [johnhall]: Sandro: translators
21:01:26 [johnhall]: Harold: this is about whole set of dialects - best practice guidance about using the lowest
21:01:42 [johnhall]: ... where to place the guidance
21:02:17 [johnhall]: ChrisW: rules authors - use lowest common case; translators - translate where you can
21:03:04 [DaveReynolds]: q-
21:03:27 [johnhall]: Michael: there will be different plug-ins, with options to save in Core - which may not be possible for some
21:04:07 [sandro]: PROPOSED: We do not define an extensibility mechanism at this stage. We'll provide some translations to Core (such as removing Do/Assert in some case) and tell producers they SHOULD do them.
21:04:58 [sandro]: PROPOSED: We will not define a fallback mechanism at this stage. We'll provide some translations to Core (such as removing Do/Assert in some case) and tell producers they SHOULD do them.
21:05:21 [johnhall]: ChrisW: this is about an explicit mechansm for fall-backs
21:05:34 [Harold]: +1
21:05:36 [sandro]: +1
21:05:48 [josb]: +1
21:05:50 [AdrianP]: +1
21:05:52 [MichaelKifer]: +1
21:05:53 [cke]: +1
21:06:02 [sandro]: PROPOSED: We will not define a fallback mechanism at this stage. We'll provide some translations to Core (such as removing Do/Assert in some case) and tell producers they SHOULD do them. (Closing issue-57)
21:06:06 [sandro]: issue-57?
21:06:06 [trackbot]: ISSUE-57 -- Does RIF specify an extensibility mechanism? -- OPEN
21:06:06 [trackbot]: http://www.w3.org/2005/rules/wg/track/issues/57
21:06:08 [DaveReynolds]: +1
21:06:20 [johnhall]: 0
21:06:28 [sandro]: RESOLVED: We will not define a fallback mechanism at this stage. We'll provide some translations to Core (such as removing Do/Assert in some case) and tell producers they SHOULD do them. (Closing issue-57)
21:07:48 [sandro]: sandro: I think BLD should drop NAU's and include some text about axiomatizing equality.
21:08:17 [sandro]: action: gary add text to PRD about how folks should get rid of do/assert when they can.
21:08:17 [trackbot]: Created ACTION-744 - Add text to PRD about how folks should get rid of do/assert when they can. [on Gary Hallmark - due 2009-04-22].
21:09:31 [johnhall]: Topic: Object Representation
21:09:39 [sandro]: action: harold draft some text for BLD about consumers doing translations-to-Core when they can.
21:09:39 [trackbot]: Created ACTION-745 - Draft some text for BLD about consumers doing translations-to-Core when they can. [on Harold Boley - due 2009-04-22].
21:09:49 [csma]: PROPOSED: Do not change anything (taking into account that PRD has an action with replacement semantics: Modify) (closing issue-94)
21:10:16 [sandro]: topic: ISSUE-94, Cardinality in Core
21:10:36 [johnhall]: ChrisW: Cardinality in Core?
21:10:51 [johnhall]: Michael: too complicated
21:11:26 [sandro]: +1
21:11:33 [josb]: +1
21:11:35 [johnhall]: csma: no time to add new things that will raise new issues with no time to resolve
21:11:39 [DaveReynolds]: +1
21:11:45 [Harold]: +1
21:11:48 [cke]: +1
21:11:50 [AdrianP]: +1
21:12:48 [johnhall]: Michael: will not be the same in dialects as in Core
21:12:56 [johnhall]: ChrisW: has to be
21:13:21 [johnhall]: Michael: same semantics, different repesentation
21:14:07 [AxelPolleres]: +1
21:14:07 [sandro]: PROPOSED: Close issue-94, without adding cardinality constraints, and with PRD having an action with replacement semantics (modify).
21:14:36 [cke]: +1
21:14:38 [sandro]: PROPOSED: Close issue-94, without adding cardinality constraints, or other object-representation beyond frames, and with PRD having an action with replacement semantics (modify).
21:14:50 [AdrianP]: +1
21:14:51 [MichaelKifer]: +1
21:14:54 [sandro]: +1
21:14:55 [johnhall]: +1
21:14:56 [DaveReynolds]: +1
21:14:57 [Harold]: +1
21:15:11 [AxelPolleres]: +1
21:15:12 [ChrisW]: +1
21:15:14 [GaryHallmark]: 0
21:15:18 [sandro]: RESOLVED: Close issue-94, without adding cardinality constraints, or other object-representation beyond frames, and with PRD having an action with replacement semantics (modify).
21:15:36 [ChrisW]: Gary: would have prefered to have cardinality constraints
21:15:46 [ChrisW]: action: chris to close issue-94
21:15:46 [trackbot]: Created ACTION-746 - Close issue-94 [on Christopher Welty - due 2009-04-22].
21:15:49 [ChrisW]: rrsagent, pointer?
21:15:49 [RRSAgent]: See http://www.w3.org/2009/04/15-rif-irc#T21-15-49
21:16:08 [ChrisW]: action: chris to close issue-57
21:16:09 [trackbot]: Created ACTION-747 - Close issue-57 [on Christopher Welty - due 2009-04-22].
21:16:57 [sandro]: thanks, DaveReynolds !
21:16:58 [ChrisW]: bye dave, and thanks
21:16:58 [Zakim]: -DaveReynolds
21:17:07 [Zakim]: -W3C
21:17:08 [Zakim]: SW_RIF(F2F)8:00AM has ended
21:17:08 [Zakim]: Attendees were DaveReynolds, W3C
21:18:24 [johnhall]: Topic: XML Schemata
21:18:58 [johnhall]: cke: Core
21:20:21 [johnhall]: csma: What has been added?
21:20:53 [Harold]: http://www.w3.org/2005/rules/wiki/Core#Appendix:_XML_Schema_for_RIF-Core
21:20:57 [johnhall]: cke: 'Atomic' was 'atom' and 'frame'
21:21:52 [johnhall]: csma: requires that PRD changes as well
21:22:30 [johnhall]: Harold: because 'atomic' should not be in head
21:24:11 [johnhall]: csma: though that 'subclass' had been removed
21:24:31 [johnhall]: cke: to check 'subclass' for PRD
21:25:43 [johnhall]: csma: 'subclass' should be in 'FORMULA', but not in 'ATOMIC'
21:28:00 [johnhall]: ChrisW: add comment about why 'Atoms' are not 'ATOMIC@
21:28:18 [johnhall]: 'ATOMIC' not 'ATOMIC@
21:33:24 [Harold]: Equal ::= TERM '=' ( TERM | IRIMETA? 'External' '(' Expr ')' )
21:33:28 [ChrisW]: issue: drop restriction in core that there are no nested externals
21:33:28 [trackbot]: Created ISSUE-99 - Drop restriction in core that there are no nested externals ; please complete additional details at http://www.w3.org/2005/rules/wg/track/issues/99/edit .
21:33:37 [johnhall]: Michael: drop the restriction that externals cannot be nested
21:35:20 [Harold]: "Thus, while function applications are not allowed as arguments to predicates, built-in and externally defined functions are permitted inside equalities. "
21:35:41 [Harold]: (http://www.w3.org/2005/rules/wiki/Core#Terms_of_RIF-Core)
21:37:45 [Harold]: NmNot ---> InflaNot
21:38:33 [johnhall]: cke: CoreRule
21:40:18 [johnhall]: csma: removed sections because we have decided not to have extension mechanism
21:40:29 [johnhall]: cke, not csma
21:41:07 [ericP]: ericP has joined #rif
21:41:13 [ericP]: is axel around?
21:41:39 [johnhall]: Gary: 'AndAction' should be 'And' in Core
21:42:36 [johnhall]: axel is here, but not in the room at the moment
21:43:45 [ChrisW]: issue: add and back into Core conclusion
21:43:45 [trackbot]: Created ISSUE-100 - Add and back into Core conclusion ; please complete additional details at http://www.w3.org/2005/rules/wg/track/issues/100/edit .
21:44:44 [johnhall]: csma: BLD should have conjunction in head
21:45:52 [csma]: s/BLD should/we have a resolution that BLD/
21:51:10 [ChrisW]: action: csma to add modify to PRD spec as we defined it
21:51:11 [trackbot]: Created ACTION-748 - Add modify to PRD spec as we defined it [on Christian de Sainte Marie - due 2009-04-22].
21:57:29 [Harold]: <xs:attribute name="ordered" type="xs:string" fixed="yes"/>
21:59:38 [johnhall]: csma: 'And' is already defined in the condition block
22:00:01 [johnhall]: Gary; in BLD is a different production
22:00:29 [johnhall]: Harold: have to define context
22:00:45 [johnhall]: csma: should be the same
22:01:38 [johnhall]: Gary: without context, will get a syntax error in BLD
22:02:21 [johnhall]: csma: who will do similar exercise for BLD
22:02:45 [johnhall]: Harold: may be so artificial that we won't want to do it
22:03:25 [johnhall]: csma: one way to test is to rewrite BLD on top of Core schema
22:04:23 [johnhall]: ChrisW: any idea how much work to rewrite Core import?
22:04:54 [johnhall]: ChrisW: postpone consideration until tomorrow
22:05:33 [ChrisW]: adjourned
22:07:05 [GaryHallmark]: I added proposed List builtins at http://www.w3.org/2005/rules/wiki/Lists#List_Builtins
22:08:46 [ChrisW]: http://maps.yahoo.com/#mvt=m&lat=42.364408&lon=-71.089943&zoom=17&q1=1%2520Kendall%2520Sq%252C%2520Cambridge%252C%2520MA%252C%252002139
22:10:50 [MichaelKifer]: MichaelKifer has left #rif