IRC log of rif on 2008-02-21

Timestamps are in UTC.

08:20:43 [RRSAgent]
RRSAgent has joined #rif
08:20:43 [RRSAgent]
logging to http://www.w3.org/2008/02/21-rif-irc
08:21:26 [ChrisW]
Meeting: RIF FTF9 Feb 21
08:21:33 [JeffP]
JeffP has joined #rif
08:21:36 [ChrisW]
Chair: Chris Welty and Christian de Sainte-Marie
08:21:46 [ChrisW]
Agenda: http://www.w3.org/2005/rules/wg/wiki/F2F9
08:21:52 [ChrisW]
Scribe: AxelPolleres
08:22:02 [AxelPolleres]
scribenick: AxelPolleres
08:22:52 [AxelPolleres]
christian: objective is finishing BLD
08:23:37 [GaryHallmark]
GaryHallmark has joined #rif
08:23:41 [AxelPolleres]
... see agenda slides.
08:24:08 [AxelPolleres]
... next objective (if time) Core, PRD.
08:24:35 [AxelPolleres]
... agenda, see http://www.w3.org/2005/rules/wg/wiki/F2F9
08:27:21 [AxelPolleres]
Topic: Review of FLD+BLD reviews
08:29:57 [AxelPolleres]
ChrisW: we start wih Igor's FLD review. http://lists.w3.org/Archives/Public/public-rif-wg/2008Feb/0048.html
08:31:25 [AxelPolleres]
Christian: XML serialization not present in the current draft. Do we want to publish without?
08:31:53 [AxelPolleres]
Harold: I can easily add a paragraph.
08:32:13 [AxelPolleres]
MichaelK: in the next draft it will be extended.
08:32:39 [AxelPolleres]
christian: maybe less critical, since we have XML in BLD.
08:32:56 [AxelPolleres]
... but we may get back to this in the extensibility discussion.
08:33:34 [AxelPolleres]
Sandro: the FLD document is not the right place, since this is only about logic dialects.
08:34:00 [AxelPolleres]
s/place,/place for the discussion of the XML syntax/
08:35:34 [AxelPolleres]
christian: comments on 2.0.2 alphabet ... done
08:35:57 [AxelPolleres]
... 2.0.4 Sigantures ... done.
08:36:17 [AxelPolleres]
... 2.0.5 ... done
08:36:50 [JeffP]
JeffP has joined #rif
08:37:14 [AxelPolleres]
... 2.0.6 Symbol Spaces: some discussion about why we don't support all XML schema types.
08:37:30 [AxelPolleres]
MichaelK: some discussion at last f2f with jos.
08:38:26 [AxelPolleres]
josb: we didn't discuss what "supports" means. the problem is that we haven't clear here what/how to extend the basic datatyes to the reader.
08:39:18 [DaveReynolds]
DaveReynolds has joined #rif
08:39:20 [AxelPolleres]
josb: suggest that we "support" all XML Schema types and "require" compliant engines to support a basic set.
08:40:15 [sandro_]
sandro_ has joined #rif
08:40:18 [AxelPolleres]
sandro: (Can you type in your concern?)
08:41:27 [AxelPolleres]
Harold: How do we cross-reference to other W3C specs in general in general and in this case in XML Schema?
08:41:43 [AxelPolleres]
s/in XML/to XML/
08:41:50 [sandro_]
Uh oh, DaveReynolds....
08:41:56 [sandro_]
Zakim, this is RIF
08:41:56 [Zakim]
sorry, sandro_, I do not see a conference named 'RIF' in progress or scheduled at this time
08:42:25 [Hassan]
Dave: working on the phone line ...
08:42:26 [sandro_]
zakim, room for 4?
08:42:27 [Zakim]
ok, sandro_; conference Team_(rif)08:42Z scheduled with code 26631 (CONF1) for 60 minutes until 0942Z
08:42:39 [sandro_]
DaveReynolds, us this one CONF1 for now.
08:43:13 [sandro_]
we're dialing now.
08:43:13 [Zakim]
Team_(rif)08:42Z has now started
08:43:20 [Zakim]
+??P0
08:44:20 [Zakim]
+??P1
08:44:37 [sandro_]
Zakim, ??P1 is MeetingRoom
08:44:37 [Zakim]
+MeetingRoom; got it
08:45:41 [AxelPolleres]
Jeff: Some datatypes such as duration, entity are not realy "RDF-friendly"
08:45:56 [AxelPolleres]
s/realy/really/
08:46:56 [AxelPolleres]
ChrisW: How we came to our current list was that we wanted to suggest a core list for compliance and recommend support for all basic XML Schema types.
08:49:41 [AxelPolleres]
josb: general confusion types that "RIF supports" vs. " are required to be supported by inference engines"
08:50:03 [DaveReynolds]
Supporting an integer but not a decimal is vastly more likely!
08:50:51 [AxelPolleres]
MichaelK: e.g. an engine that doesn't understand integer, but decimal would be able to deal with integers.
08:51:25 [DaveReynolds]
q+
08:52:53 [JeffP]
ack DaveReynolds
08:52:58 [AxelPolleres]
christian: instead of making this subtle difference, would it be easier to define in geeneral that consuming engines translate datatypes in to their datatypes which have the same semantics?
08:53:36 [AxelPolleres]
dave: that's the implementers' business, has nothing to do with RIF compliance/compatibility
08:54:55 [AxelPolleres]
... why should RIF in the spec separate what is in the engine and in the language. what is in the engine is irrelevant, if the engine has to take care of the translation.
08:55:07 [AxelPolleres]
(hope I got that more or less right, dave)
08:56:02 [AxelPolleres]
sandro: so if you support short and somebody adds 50000+50000 you are outside short, but not if you internally translate it to integer.
08:56:26 [AxelPolleres]
... but if our error semantics is that it is undefined how you handle errors than it would be ok.
08:56:38 [sandro_]
Dave: if we have builtins for testing types (isShort) then it will change the semantics.
08:57:23 [AxelPolleres]
MichaelK: maybe we should just delete the paragraph about what a RIF consumer engine is supposed to to about datatypes.
08:57:45 [AxelPolleres]
... the idea to put it in was to simplify the job of implementers
08:58:29 [AxelPolleres]
josb: we don't really want to restrict the datatypes you are allowed to use, but we didn't want to impose all engine with the rif stamp to have to support all.
09:00:03 [AxelPolleres]
christian: want to keep the paragraph.
09:00:13 [AxelPolleres]
josb: also want to keep it.
09:00:49 [AxelPolleres]
MichaelK: RIF systems still have to support all the built-ins.
09:01:32 [DaveReynolds]
-1 to keeping paragraph, see my review
09:01:44 [AxelPolleres]
josb: the problem at the moment is the (editorial) use of the words supports, compliant, consuming, etc. needs to be clarified.
09:02:09 [AxelPolleres]
MiachelK: we could spell out subtypes.
09:04:00 [AxelPolleres]
christian: remove "compliant" but only distinguish "producing" and "consuming" engines.
09:04:44 [AxelPolleres]
michaelK: possibly break out datatypes in a separate document, at least keep the discussion on datatypes in one place... now scattered.
09:05:21 [AxelPolleres]
harold/michaelK: could be part of builtins document.
09:06:03 [AxelPolleres]
sandro/chrisw: Core document would make sense.
09:06:23 [AxelPolleres]
chrisw: paula was currently editor of builtins, but she is leaving the WG.
09:06:31 [AxelPolleres]
harold: I took over.
09:08:58 [sandro_]
sandro: just say "RIF does not define semantics for xsd:Duration"
09:09:10 [AxelPolleres]
axel: what should now be part of core and what of extensibility?
09:09:34 [sandro_]
PROPOSED: Move text on datatypes and symbol spaces to Core
09:09:45 [DaveReynolds]
What is Core? What happened to Arch?
09:10:16 [csma]
PROPOSED: Move text on datatypes and symbol spaces to Core
09:10:21 [sandro_]
Chris: What is Arch? (laugh)
09:11:03 [DaveReynolds]
Arch = Architecture, which was originally precisely were the menu of builtins, datatypes, core XML syntax etc were going to be defined :-)
09:11:09 [DaveReynolds]
s/were/where/
09:11:28 [AxelPolleres]
(some discussions on how to resize font on projector... ;-) )
09:12:21 [AxelPolleres]
chrisw: FLD covers a good part of what I understood was "arch"
09:12:33 [AxelPolleres]
... can we extend it?
09:12:49 [AxelPolleres]
michaelK: easier to write something more specific.
09:13:05 [sandro_]
csma: The reason to have datatypes and builtins in Core, not Arch, is because it's a specific thing that has to be implemented in every dialect.
09:13:05 [AxelPolleres]
chrisw: is there an active Core document.
09:13:18 [AxelPolleres]
axel: no, because we stil discuss what should be in there.
09:13:29 [AxelPolleres]
s/discuss/need to discuss/
09:13:54 [AxelPolleres]
sandro: We need to clarify what core is actually gonna be.
09:14:39 [sandro_]
sandro: (correction) We're getting a sense of what Core is actually going to be. BLD minus function terms, equality, and a few other things.
09:15:00 [sandro_]
axel: What of datatypes are Core, and what are extensibility?
09:15:28 [sandro_]
csma: The part of Datatypes that goes into Core is NOT the symbol spaces stuff (that's FLD), but the LIST OF DATATYPES goes into Core.
09:15:34 [AxelPolleres]
christian: definition od symbol spaces, datatypes in general belong to FLD.
09:15:51 [sandro_]
Jos: but we don't want Core dependent on FLD!
09:16:03 [AxelPolleres]
... core supported datatypes in Core.
09:16:15 [sandro_]
RRSAgent, pointer?
09:16:15 [RRSAgent]
See http://www.w3.org/2008/02/21-rif-irc#T09-16-15
09:17:46 [AxelPolleres]
MichaelK: nothing depends on FLD, we have XML datatypes, etc.
09:18:31 [JeffP]
q?
09:18:33 [AxelPolleres]
christian: how does putting the list of datatypes in Core make core dependent on FLD.
09:19:10 [AxelPolleres]
... and why is it a problem to depend on FLD, core IS a logic dialect.
09:20:20 [sandro_]
Axel: in AnswerSet programming, they are thinking about an exchange format, I suggested they use RIF -- they said it was too complicated.
09:20:36 [sandro_]
Chris: ACTION Axel!
09:20:52 [sandro_]
Axel: Harold and I were thinking about it.
09:21:14 [sandro_]
Axel: And it doesn't make sense to do it until the spec settles down.
09:21:46 [sandro_]
Axel: This community knows their semantics, they want to see our XML syntax.
09:22:22 [sandro_]
csma: This is like the PRD draft. They syntax is described so that people who already know their semantics can just use it.
09:22:42 [sandro_]
csma; This is different from FLD. This is how you present the syntax of a specific dialect.
09:23:19 [sandro_]
csma: The way the syntax is currently presented in BLD is probably a problem for the language developer, just trying to build a translator.
09:23:50 [sandro_]
MichaelKifer: I suspect the AnswerSet critique refers to the old version of BLD that was much more complex.
09:24:22 [AxelPolleres]
hassan: the documents are still too dense, we need some introductory document(s)
09:24:45 [AxelPolleres]
sandro: not our job to explain it... others can write tutorials.
09:25:30 [AxelPolleres]
gary: testcases document would do a great part of that job already.
09:25:34 [sandro_]
sandro: (it's okay for us to explain it -- but it's not a requirement on us.)
09:25:55 [AxelPolleres]
chrisw: it is more a question of bandwidth
09:26:18 [AxelPolleres]
michaelk: we definitly need an entry-point document.
09:26:26 [AdrianP]
testcases + XML content models of RIF + use cases showing examples
09:26:48 [AxelPolleres]
... a tutorial (as planned by harold,axel,me) is separate from that.
09:27:18 [AxelPolleres]
adrian: add syntax to the use cases.
09:28:03 [AxelPolleres]
christian: the style of syntax presentation at the moment is not the style which developers are used to.
09:30:20 [AdrianP]
syntax can be writen as reference menu
09:30:50 [AdrianP]
like a glossary
09:31:34 [DaveReynolds]
The current syntax is not that precise, there are many boring details left out. A developer needs clearer presentation, with clearer and more comprehensive examples and test cases.
09:31:58 [AxelPolleres]
chrisw: what we are trying to achieve is a common serialization for classes of rule languages.
09:32:01 [GaryHallmark]
PRD style is more like a reference manual
09:32:26 [AxelPolleres]
ChrisW: BREAK 1/2 hour!
09:32:28 [sandro]
sandro has joined #rif
09:33:31 [Zakim]
-DaveReynolds
09:47:01 [Zakim]
disconnecting the lone participant, MeetingRoom, in Team_(rif)08:42Z
09:47:03 [Zakim]
Team_(rif)08:42Z has ended
09:47:04 [Zakim]
Attendees were DaveReynolds, MeetingRoom
10:04:17 [sandro]
DaveReynolds, tell us when you need us to call in again.
10:04:45 [GaryHallmark]
Scribe: GaryHallmark
10:04:53 [GaryHallmark]
ScribeNick: GaryHallmark
10:05:23 [GaryHallmark]
Topic: FLD/BLD reviews, continued
10:06:23 [GaryHallmark]
issue: RIF dialect can introduce new datatypes
10:07:22 [GaryHallmark]
spec should be clear that list of datatypes can be extended
10:07:38 [GaryHallmark]
chrisw: dialects must support AT LEAST the listed datatypes
10:08:39 [GaryHallmark]
csma: come back to this issue when discussing extensibility
10:09:16 [GaryHallmark]
chrisw: what is a closed rif formula (in entailment section 3.0.7)?
10:09:24 [GaryHallmark]
mk: no free vars
10:10:10 [GaryHallmark]
... entailment defined when no free vars (or implicitly universally quantified)
10:11:25 [GaryHallmark]
in BLD it is an error to have free variables (there is a resolution about this)
10:11:59 [sandro]
"The free variables in the rule can be optionally quantified with Forall outside of the rule (i.e., Forall ?vars (head :- body)). "
10:12:01 [AdrianP]
but we can hardly restrict the BLD syntax not to contain free variables
10:14:26 [sandro]
trackbot-ng, list
10:14:29 [GaryHallmark]
action on mkifer to forbid free variables
10:14:30 [ChrisW]
ACTION: Michael to make sure that BLD requires explicit quantification
10:14:30 [trackbot-ng]
Sorry, amibiguous username (more than one match) - Michael
10:14:30 [trackbot-ng]
Try using a different identifier, such as family name or username (eg. mkifer, msintek, merdmann, uscholdm)
10:14:41 [ChrisW]
ACTION: Mkifer to make sure that BLD requires explicit quantification
10:14:41 [trackbot-ng]
Created ACTION-425 - Make sure that BLD requires explicit quantification [on Michael Kifer - due 2008-02-28].
10:20:52 [ChrisW]
ACTION: Mkifer to list FLD datatype subtypes explicity
10:20:52 [trackbot-ng]
Created ACTION-426 - List FLD datatype subtypes explicity [on Michael Kifer - due 2008-02-28].
10:22:43 [GaryHallmark]
rulesets should be explained earlier in spec because it is used to define scope of rif:local
10:24:31 [ChrisW]
ACTION: Mkifer to make sure "ruleset" is used consistently in FLD/BLD
10:24:31 [trackbot-ng]
Created ACTION-427 - Make sure \"ruleset\" is used consistently in FLD/BLD [on Michael Kifer - due 2008-02-28].
10:26:26 [GaryHallmark]
define RIF-compliant processor
10:26:50 [GaryHallmark]
csma: define compliant consumer/producer
10:27:07 [GaryHallmark]
hassan: compliance is too strong a term
10:27:15 [GaryHallmark]
sandro: we do mean compliance
10:27:29 [johnhall]
johnhall has joined #rif
10:27:42 [GaryHallmark]
csma: "inference engine" is out of scope of definition
10:28:05 [GaryHallmark]
sandro: need something specific like inference engine to define test cases
10:28:59 [GaryHallmark]
csma: should focus on translation, not processing
10:29:24 [GaryHallmark]
mkifer: compliance should go elsewhere
10:29:39 [GaryHallmark]
josb: define compliance at dialect level
10:30:05 [GaryHallmark]
mkifer: need to define generally what compliance means
10:30:36 [GaryHallmark]
... but it seems out of place in FLD currently
10:31:27 [GaryHallmark]
mkifer: needs to be in Core
10:32:35 [GaryHallmark]
chrisw: realistically, will we have other docs?
10:33:32 [AxelPolleres]
current docs: FLD, BLD, SWC, UCR, PRD, (Core?). what else?
10:33:33 [GaryHallmark]
... last call for BLD in 2-3 months
10:37:14 [GaryHallmark]
mkifer: move datatypes, builtins, and compliance to another doc
10:38:23 [GaryHallmark]
chrisw: symbol spaces stays in FLD
10:39:01 [GaryHallmark]
mkifer: can move symbol spaces too
10:40:13 [ChrisW]
PROPOSED: Create a new Document with provisional titles "Data Types and Builtins"
10:40:23 [csma]
csma has joined #rif
10:40:26 [ChrisW]
PROPOSED: Create a new Document with provisional titles "Data Types and Builtins"
10:42:37 [ChrisW]
PROPOSED: Create a new Document with provisional title "Data Types and Builtins" to contain elements common to all dialects
10:43:16 [ChrisW]
PROPOSED: Create a new Document with provisional title "RIF Vulgar" to contain elements common to all dialects
10:45:26 [GaryHallmark]
much discusson about possible title and content, including "RIF Core" (again!)
10:45:57 [ChrisW]
PROPOSED: Create a new Document with provisional title "Data Types and Builtins" to contain elements common to all dialects
10:46:27 [ChrisW]
PROPOSED: Create a new Document with provisional title "Data Types and Builtins" to contain elements common to all dialects with Harold and Axel as editors
10:46:28 [GaryHallmark]
Harold and Axel will edit the new document
10:47:20 [ChrisW]
RESOLVED: Create a new Document with provisional title "Data Types and Builtins" to contain elements common to all dialects with Harold and Axel as editors
10:48:15 [ChrisW]
action: axel to create DT&B document by Friday
10:48:15 [trackbot-ng]
Created ACTION-428 - Create DT&B document by Friday [on Axel Polleres - due 2008-02-28].
10:48:49 [ChrisW]
action: mkifer to remove DT&B content from FLD
10:48:49 [trackbot-ng]
Created ACTION-429 - Remove DT&B content from FLD [on Michael Kifer - due 2008-02-28].
10:52:46 [GaryHallmark]
mkifer: producer, consumer, etc. should be defined in a common place
10:54:33 [GaryHallmark]
... also notion of dialects
10:56:21 [GaryHallmark]
... overall processing model
10:56:58 [GaryHallmark]
... need a guide (overview) of all the docs
10:57:19 [GaryHallmark]
csma: no time to create many new docs
10:58:53 [GaryHallmark]
harold: will we publish UCR?
10:59:03 [GaryHallmark]
sandro: can do last call on UCR
11:01:13 [GaryHallmark]
mkifer: I can write a 1 or 2 page overview (guide)
11:01:54 [GaryHallmark]
sandro: can take BLD to last call without overview info
11:02:37 [GaryHallmark]
... sort of OK not to understand, as long as audience doesn't misunderstand
11:03:21 [sandro]
RIF Overview Document --- explaining why and how RIF is useful to people.
11:04:10 [sandro]
csma: "A Common XML Serialization for Rule Languages"
11:04:45 [sandro]
sandro: Yes, it would be very useful to have a document which technical people can be pointed to, to convince them why they should use RIF, and point them to the details they need.
11:05:27 [GaryHallmark]
... sort of OK not to understand, as long as audience doesn't misunderstand
11:08:01 [ChrisW]
...continuing with DaveR's review: primitive data types will be fixed with new resolution
11:09:22 [sandro]
No, but we can dial in DaveReynolds if you want.
11:09:26 [GaryHallmark]
GaryHallmark has joined #rif
11:09:29 [sandro]
zakim, room for 4?
11:09:31 [Zakim]
ok, sandro; conference Team_(rif)11:09Z scheduled with code 26631 (CONF1) for 60 minutes until 1209Z
11:10:14 [Zakim]
Team_(rif)11:09Z has now started
11:10:21 [Zakim]
+??P0
11:11:36 [Zakim]
+??P1
11:11:48 [ChrisW]
zakim, ??p1 is meeting_room
11:11:48 [Zakim]
+meeting_room; got it
11:11:49 [sandro]
Zakim, ??P1 is MeetingRoom
11:11:50 [Zakim]
I already had ??P1 as meeting_room, sandro
11:12:49 [GaryHallmark]
topic: BLD reviews
11:14:27 [GaryHallmark]
josb: need single defn of
11:14:33 [GaryHallmark]
... BLD
11:15:44 [GaryHallmark]
csma: specialization of BLD from FLD should be appendix
11:16:29 [GaryHallmark]
mkifer: direct (standalone) spec should be normative
11:17:01 [GaryHallmark]
sandro: both can be normative
11:17:07 [ChrisW]
proposed: make "specialization of FLD" sections (of BLD) appendices
11:17:32 [ChrisW]
proposed: make "specialization of FLD" sections (of BLD) appendices, with both normative
11:19:43 [ChrisW]
proposed: make "specialization of FLD" sections (of BLD) appendices, leaving standalone sections in place, and making both normative
11:21:06 [josb]
proposed: make "specialization of FLD" sections (of BLD) appendices, leaving standalone sections in place, and making both standalone and specialization normative
11:21:35 [sandro]
Axel: example -- many people use RDF non-normative rule-based semantics.
11:21:37 [ChrisW]
resolved: make "specialization of FLD" sections (of BLD) appendices, leaving standalone sections in place, and making both normative
11:21:49 [ChrisW]
correction ---
11:21:51 [josb]
RESOLVED: make "specialization of FLD" sections (of BLD) appendices, leaving standalone sections in place, and making both standalone and specialization normative
11:22:10 [sandro]
csma: And that shows why they should both me normative, so if there is an error, it's the spec that is in error, not those folks and their implementation.
11:22:17 [ChrisW]
action: mkifer to move specialization sections to appendices
11:22:17 [trackbot-ng]
Created ACTION-430 - Move specialization sections to appendices [on Michael Kifer - due 2008-02-28].
11:22:38 [GaryHallmark]
issue: xml syntax is too loosely specified
11:22:51 [ChrisW]
dave, didn't hear your input during that proposed resolution - did it address your comment???
11:22:51 [GaryHallmark]
mkifer: what does loose mean?
11:23:22 [DaveReynolds]
Chris: yes, I was proposing the appendix/body be the other way round but the proposal is ok
11:23:22 [GaryHallmark]
josb: presentation to xml translation table too informal
11:23:38 [GaryHallmark]
csma: table is not enough
11:24:56 [GaryHallmark]
josb: 2 issues: want self-contained description of XML and want better translation table
11:25:15 [GaryHallmark]
csma: e.g. which elements are required, optional, etc.
11:25:47 [GaryHallmark]
mkifer: but xml schema appendix gives more info
11:26:04 [GaryHallmark]
csma: likes PRD style
11:26:43 [DaveReynolds]
EBNF is not "totally precise" !!
11:26:50 [GaryHallmark]
harold: ebnf is precise
11:28:36 [GaryHallmark]
daver: my comments critique the xml schema, too
11:30:03 [sandro]
Discussing http://lists.w3.org/Archives/Public/public-rif-wg/2008Feb/0077.html
11:31:11 [GaryHallmark]
daver: most of my comments are relatively minor but are important to ensure interop
11:33:08 [GaryHallmark]
... distinguish between IRIs and CURIes
11:34:30 [GaryHallmark]
daver: why equality in rule bodies in CORE?
11:34:48 [GaryHallmark]
mkifer: because it is easy if just in bodies
11:35:20 [GaryHallmark]
... sugar for equal(?x ?x)
11:36:53 [GaryHallmark]
sandro: but what about classical negation and = ?
11:37:28 [GaryHallmark]
josb: datalog + classical negation => disjunctive datalog
11:37:30 [sandro]
Jos: IE disjunctive datalog.
11:39:38 [sandro]
MichaelKifer: you can define equal(?x,?x)
11:39:59 [GaryHallmark]
consensus is to remove equality from core to prevent problems with future extensions of core
11:40:30 [AdrianP]
if strong negation is only defined in the body you don't run into conflicts between positive and negative conclusions
11:40:51 [sandro]
csma: is this a real Resolution?
11:41:35 [AxelPolleres]
Just as it comes to my head:
11:41:47 [AxelPolleres]
do we want to allow unsafe rules in CORE?
11:43:40 [GaryHallmark]
mkifer: to prove not(equal(1,3)) you must have such a fact
11:43:46 [AxelPolleres]
unsafe = all variables in head must be bound by a (non-built-in) presicate in the body (if disjunction in the body additional care is needed)
11:43:55 [AxelPolleres]
s/unsafe/safe
11:44:30 [Zakim]
-DaveReynolds
11:44:40 [Zakim]
-meeting_room
11:44:41 [Zakim]
Team_(rif)11:09Z has ended
11:44:42 [Zakim]
Attendees were DaveReynolds, meeting_room
12:41:32 [johnhall]
johnhall has joined #rif
12:45:23 [mdean]
mdean has joined #rif
12:47:13 [mdean]
is there a telecon dialin? Zakim didn't recognize RIFWG#
12:47:58 [GaryHallmark]
GaryHallmark has joined #rif
12:56:30 [sandro]
zakim, room for 4?
12:56:32 [Zakim]
ok, sandro; conference Team_(rif)12:56Z scheduled with code 26631 (CONF1) for 60 minutes until 1356Z
12:56:51 [Zakim]
Team_(rif)12:56Z has now started
12:56:58 [Zakim]
+??P3
12:57:06 [sandro]
zakim, ??P3 is MeetingRoom
12:57:06 [Zakim]
+MeetingRoom; got it
12:57:17 [AxelPolleres]
AxelPolleres has joined #rif
12:57:19 [ChrisW]
i'm here
12:57:25 [AxelPolleres]
I'm there
12:57:30 [sandro]
I'm not
12:57:46 [josb]
josb has joined #rif
12:57:47 [ChrisW]
France makes us all existential
12:57:51 [ChrisW]
(by default)
12:57:59 [mdean]
mdean has joined #rif
12:58:07 [ChrisW]
mike, the code is 26631
12:59:26 [ChrisW]
mike, u there?
13:00:19 [josb_]
josb_ has joined #rif
13:05:01 [mdean]
mdean has joined #rif
13:05:11 [Harold]
Harold has joined #rif
13:06:20 [sandro]
Zakim, who is on the call?
13:06:20 [Zakim]
On the phone I see MeetingRoom
13:06:35 [sandro]
mdean???
13:07:59 [csma]
csma has joined #rif
13:09:09 [sandro]
scribeNick: AdrianP
13:09:16 [sandro]
Topic: SWC
13:09:57 [AdrianP]
Jos: Explains the four different entailment regimes fro RDF integration
13:10:29 [AdrianP]
Jos: Explains difference of OWL DL and OWL Full compatibility in RIF
13:10:48 [sandro]
jos: OWL Full a[subckass->b] OWL DL: all b(x) :- a(x)
13:11:38 [sandro]
jos: So we read things with a special semantics. a[rdf:type->b] : b(a)
13:11:55 [sandro]
Jos: and a[p->b] : p(a,b)
13:12:20 [AdrianP]
Jos: a [p -> b]: p(a,b)
13:12:27 [AdrianP]
Jos: p might be a variable
13:12:50 [sandro]
Jos: Syntactically in blf frames, p could be variable.
13:12:55 [sandro]
s/blf/bld/
13:13:46 [csma]
zakim, who is on the phone?
13:13:46 [Zakim]
On the phone I see MeetingRoom
13:13:54 [Harold]
Harold has joined #rif
13:14:06 [AdrianP]
Jos: interpretation of frames for the OWL Full compatibility workaround solution is different from the interpration in RIF FLD
13:15:26 [AdrianP]
Jos: a[p->b] <-> a[q->b]
13:15:45 [AdrianP]
Jos: i.e. q equivalent to p
13:17:14 [AdrianP]
Sandor: distinguish the different interpretations of frames in RIF FLD and OWL compatibility also syntactically
13:17:37 [AdrianP]
Jos: RDFS: a sc b
13:17:55 [AdrianP]
Jos: RIF d [type -> a]
13:18:18 [AdrianP]
Jos: q[q->d] <- x [type -> b]
13:18:38 [AdrianP]
Jos: OWL DL: you can not use this rules anymore
13:19:49 [Zakim]
+ +1.617.873.aaaa
13:20:23 [mdean]
zakim, aaaa is mdean
13:20:23 [Zakim]
+mdean; got it
13:20:40 [AdrianP]
Zakim, who is on the phone?
13:20:40 [Zakim]
On the phone I see MeetingRoom, mdean
13:21:30 [AdrianP]
Jos: In general frame syntax is incompatble from predicate syntax
13:21:50 [AdrianP]
Sandro: Expressions from OWL DL could be translated into both syntaxes
13:22:35 [AdrianP]
Sandro: How can you read it differently?
13:22:47 [AdrianP]
Jos: It is defined in the semantics
13:22:58 [AdrianP]
sandro: We need something more concrete
13:23:48 [AdrianP]
Jos: I |= a[type -> b] if I |= b(a)
13:24:00 [AdrianP]
Sandro: How can this processed in the software
13:24:45 [AdrianP]
Jos: I imagine that somewhere in the rule set it is made explicitly
13:25:34 [AdrianP]
Jeff: Why do we need to worry about rewriting a particular OWL statement
13:25:46 [AdrianP]
Jos: We don't rewrite
13:27:21 [AdrianP]
Jos: In RDFS the syntax can be frames
13:27:42 [AdrianP]
Jos: But in OWL DL they are classes
13:28:29 [AdrianP]
Jos: We want to use the same syntax for both
13:30:04 [AdrianP]
Jos: Use frame syntax as unifier
13:30:11 [AdrianP]
Jeff: but you change the semantics
13:30:38 [AdrianP]
Jeff: if you want to use different ontologies you will change the semantics
13:32:13 [sandro]
Sandro: So, I'm satisfied with Jos' explanation of why we need the two syntaxes and how they relate, but I think the document is going to [somehow] have to be a lot clearer here.
13:32:21 [sandro]
Jos: Yeah.
13:32:59 [sandro]
zakim, who is on the call?
13:32:59 [Zakim]
On the phone I see MeetingRoom, mdean
13:33:38 [AdrianP]
Harold: we can use different way to write it syntactically
13:34:01 [AdrianP]
Adrian: if we are only talking about instance and subcalls we can use a typed logic syntax
13:34:49 [AdrianP]
ChrisW: the choices are binary predicate syntax or frames
13:34:51 [sandro]
Chris: For a user, there's an awkward choice between using frame vs predicate syntax. There's no real guidance as to whether to chose one over the other.
13:35:12 [AdrianP]
Jos: then use onyl frames with different semantic interpretation
13:35:30 [sandro]
Sandro: (joking) it'll be easy -- frames will be slower
13:35:44 [sandro]
MichaelKifer: (taking it serously) not with good indexing
13:36:04 [sandro]
GaryHallmark: (also seriously) Java impls may just use the VM to do it, and be faster than predicates.
13:36:51 [AdrianP]
s/subcalls/subclass
13:37:48 [AdrianP]
Jos: BLD: I |= a[b->c] if <aI,cI> in Iframe (bI)
13:38:18 [AdrianP]
Jos: That is the semantics of BLD
13:38:32 [AdrianP]
Mikeal: Yes, it captures the meaning
13:39:10 [AdrianP]
s/Mikeal/Michael
13:41:24 [AdrianP]
Jeff: I'm in favor of a syntactical destinction instead of a different semantic interpretation of frames when using OWL DL
13:41:40 [AdrianP]
Michael: The problem is with extensions
13:42:15 [sandro]
Chris: What about just having this modified frame semantics in BLD? [[that's where MK said problem with extensions]]
13:44:13 [sandro]
MichaelKifer: we put predicates out of the domain, to be precisely like first-order-logic (even though it would be first order, anyway)
13:44:20 [AdrianP]
Michael: We wanted to stay close to first order
13:46:33 [AdrianP]
Michael: We need an explanation of frames in the OWL compatibiltiy section
13:46:50 [sandro]
Sandro: RIF FAQ #4: Why do you have Frames and Predicates, and why aren't they equivalent?
13:48:38 [sandro]
Jos: example with domain of size one. in OWL DL, it's not true that all classes are now the same.
13:50:03 [AdrianP]
Jeff: Let the users define which sort of semantics they would like to go for
13:50:37 [AxelPolleres]
Jeff, do I interpret you right, you said: Everything is fine except ... OWL DL? ;)
13:50:47 [AdrianP]
Jeff: There is only one semantics for OWL DL
13:51:11 [AdrianP]
ChrisW: no and OWL DL ontology can be also interpreted with OWL Full semantics
13:51:12 [sandro]
Chris/Jos: OWL DL has this implicit choice (are you using OWL DL or OWL Full semantics), and that carries through to RIF, when you use RIF+OWL.
13:51:34 [AdrianP]
Jess: You can specify the semantics by an additional attribute
13:51:43 [sandro]
s/Jess/Jeff
13:51:43 [AdrianP]
s/Jess/Jeff
13:51:47 [sandro]
:-)
13:52:20 [AdrianP]
Jos: Semantics is defined for the combinations
13:52:43 [AdrianP]
Jos: RIF-OWL Full; RIF-OWL DL
13:53:32 [AdrianP]
Chris: You choose by using a tool
13:53:50 [AdrianP]
Chris: You get potential different results depending which reasoner you use
13:54:35 [mdean]
my other meeting is about to start - i'll try to call in again tomorrow - thanks!
13:54:38 [AdrianP]
Hassan: Think of Datalog and Prolog interpreters
13:54:48 [AdrianP]
bye Mike
13:55:09 [Zakim]
-mdean
13:55:11 [AdrianP]
Sandro: We can not solve this problems between OWL DL and OWL Full in our group
13:55:32 [AdrianP]
Chris: Next step?
13:55:36 [sandro]
Sandro: ... but the difference in entailments is, in practice, unimportant.
13:56:05 [AdrianP]
Jos: wether and how do we point to RDF graphs
13:56:12 [AdrianP]
Jos: which entailment regime to use
13:56:56 [AdrianP]
Axel: define imports of RDF data by using owl:import
13:57:19 [sandro]
Axel: option: define an RDF thing like owl:imports for importing a ruleset from inside RDF.
13:58:32 [AdrianP]
reviews to RDF/OWL compatibility documents
13:59:13 [sandro]
Zakim, what is the code?
13:59:13 [Zakim]
the conference code is 26631 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), sandro
14:01:01 [Zakim]
disconnecting the lone participant, MeetingRoom, in Team_(rif)12:56Z
14:01:03 [Zakim]
Team_(rif)12:56Z has ended
14:01:05 [Zakim]
Attendees were MeetingRoom, +1.617.873.aaaa, mdean
14:04:06 [AdrianP]
Axel: Review of Axel
14:04:53 [AdrianP]
Axel: some editorial issues
14:05:12 [AdrianP]
Axel: imports of OWL ontologies
14:05:36 [AdrianP]
Axel: bi-directional or uni-directional imports
14:06:07 [AdrianP]
Chris: it is reasonable that RIF can import anything
14:09:24 [AdrianP]
Axel: number 10 : example in section 2
14:14:18 [AdrianP]
Axel: number 11: is there a way to have it defined for standard RDF graphs instead of extende RDF graphs
14:14:50 [AdrianP]
Axel: make a distinction in the examples
14:15:28 [AxelPolleres]
<http://a> <http://p> <http://b> .
14:15:29 [AxelPolleres]
<http://a> "http://p"^^rif:iri "http://b"^^rif:iri .
14:15:30 [AxelPolleres]
"http://a"^^rif:iri <http://p> "http://b"^^rif:iri .
14:19:53 [DaveReynolds]
DaveReynolds has joined #rif
14:26:30 [AdrianP]
Zakim, who is on the phone?
14:26:30 [Zakim]
apparently Team_(rif)12:56Z has ended, AdrianP
14:26:31 [Zakim]
On IRC I see DaveReynolds, Harold, csma, mdean, josb, AxelPolleres, GaryHallmark, johnhall, sandro, JeffP, RRSAgent, Zakim, MichaelKifer, ChrisW, AdrianP, Hassan, trackbot-ng
14:28:02 [AdrianP]
Axel: comment 22
14:29:57 [AdrianP]
Axel: do you get ill-typed literals with using RIF-RDF
14:31:02 [AdrianP]
Chris: p(1). p(a). + (x,1) -> p(x)
14:31:15 [AdrianP]
Michael: that is not ill-typed
14:32:49 [ChrisW]
action: Axel to do what he just said
14:32:50 [trackbot-ng]
Created ACTION-431 - Do what he just said [on Axel Polleres - due 2008-02-28].
14:33:27 [ChrisW]
action: axel to make a strange use case to generate ill-typed literals
14:33:28 [trackbot-ng]
Created ACTION-432 - Make a strange use case to generate ill-typed literals [on Axel Polleres - due 2008-02-28].
14:33:51 [AdrianP]
Axel: comment 24
14:34:02 [AdrianP]
Axel: comment 25
14:36:56 [AdrianP]
Axel: comment 26
14:39:09 [AdrianP]
Axel: comment 28: replace condition 4 by condition 4'
14:41:55 [AdrianP]
break!
15:04:12 [JeffP]
zakim, who is on the phone?
15:04:22 [Zakim]
apparently Team_(rif)12:56Z has ended, JeffP
15:04:24 [Zakim]
On IRC I see DaveReynolds, Harold, csma, mdean, josb, AxelPolleres, GaryHallmark, johnhall, sandro, JeffP, RRSAgent, Zakim, MichaelKifer, ChrisW, AdrianP, Hassan, trackbot-ng
15:06:20 [csma]
Dave, we reconvene
15:06:59 [sandro]
DaveReynolds, you want to call in?
15:07:17 [sandro]
zakim, room for 4?
15:07:18 [Zakim]
ok, sandro; conference Team_(rif)15:07Z scheduled with code 26631 (CONF1) for 60 minutes until 1607Z
15:07:47 [Zakim]
Team_(rif)15:07Z has now started
15:07:49 [Zakim]
+??P37
15:07:59 [sandro]
Zakim, ??P37 is Meeting_Room
15:07:59 [Zakim]
+Meeting_Room; got it
15:08:04 [sandro]
okay, DaveReynolds
15:08:35 [Zakim]
+ +44.145.441.aaaa
15:08:37 [Zakim]
- +44.145.441.aaaa
15:08:39 [Zakim]
+ +44.145.441.aaaa
15:09:20 [Hassan]
Review of MK's BLD document...
15:15:17 [sandro]
Sandro: let's take out the section on SubDialects of BLD. It's not something you need to know to implement BLD.
15:15:31 [sandro]
Chris: Yeah, it's touting the power of the framework.
15:15:32 [Hassan]
Discussing syntactic equality ... Should we remove it from BLD (because of pbs with constructive negation)?
15:16:44 [sandro]
Sandro: Or maybe move it to an appendix.
15:16:49 [Hassan]
CSMA: Need to make precise what is BLD and what is "core"...
15:18:02 [sandro]
we/re talking about http://www.w3.org/2005/rules/wg/draft/ED-rif-bld-20080219/#head-b19db0cd1e4a596ea80c534c9e481ccc4fde020d
15:18:55 [sandro]
Harold: or put it in an overview.
15:19:52 [Hassan]
ChrisW - suggests to remove all mention of sub-dialiects in BLD - perhaps could be in FLD?...
15:20:10 [Hassan]
MK: do we - or not - need to define a core?
15:21:24 [Hassan]
Sandro and CSMA: propose to ask for feedbakc from eventual reviewers of the published document
15:21:35 [Hassan]
s/feedbakc/feedback/
15:22:26 [Hassan]
MK: who is going to take this up (i.e. core) - Sandro?
15:23:46 [sandro]
Chris: Let's go with an Appendix.
15:23:56 [sandro]
(move 2.0.9 into an appendix.)
15:23:56 [Hassan]
MK: core is BLD minus some stuff ...
15:24:17 [sandro]
ACTION: mkifer to move 2.0.9 to an appendix
15:24:18 [trackbot-ng]
Created ACTION-433 - Move 2.0.9 to an appendix [on Michael Kifer - due 2008-02-28].
15:24:44 [Hassan]
Issues ...
15:25:09 [Hassan]
ChrisW: we were close to an agreement on named arguments ...
15:25:52 [Hassan]
ChrisW: if a system does not support named args, what can they do (knowing that they are the majority)?
15:26:27 [Hassan]
ChrisW: one way is to take named args as sytactic sugar...
15:26:37 [Hassan]
s/sytactic/syntactic/
15:27:09 [Hassan]
ChrisW: All args *must* mys either named or positional, and none must be missing
15:27:22 [Hassan]
s/mys/be/
15:28:42 [sandro]
Chris: (on board) Arg.Names are not necessarily distinct.
15:28:51 [sandro]
MichaelKifer: we could make them distinct.
15:29:16 [Hassan]
ChrisW: order of names does not matter
15:29:28 [sandro]
ChrisW: (on board) P( a->b a->c ) == P( a->c a->b ) right? MichaelKifer: Yes.
15:31:22 [Hassan]
MK: proposing to define dialects in a modular way extending BLD
15:31:47 [Hassan]
CSMA: why not use a cononical rep (say, by sorting the names)?
15:31:59 [Hassan]
s/cononical/canonical/
15:32:10 [sandro]
Chris: So the NUMBER of repeatable argument names has to be constant? MichaelKifer: Yes.
15:33:16 [sandro]
PROPOSED: make argument names distinct
15:33:33 [sandro]
RESOLVED: make argument names distinct
15:34:12 [sandro]
(in France, they supply bottles of wine, on which to toast our resolutions!)
15:34:36 [sandro]
Chris: lexical ordering? MichaelKifer: but they are not strings.
15:35:41 [sandro]
ChrisW: P(a->b c->d) = P(b d) Sandro: isn't it P' ?
15:37:26 [sandro]
Jos: I'd like them to be the same.
15:37:36 [sandro]
Hassan: That means names are useless!
15:37:47 [sandro]
Sandro,Gary: They are just comments.
15:40:19 [Harold]
There are several Use Cases for Named Arguments:
15:40:19 [sandro]
Hassan: If arguments could be omitted, and predicates could be overloaded, THEN this would be useful.
15:40:30 [Harold]
* ISO Common Logic
15:40:35 [Harold]
* CLIPS
15:40:45 [Harold]
* Relational Tables
15:41:15 [Harold]
* CycL
15:41:17 [Harold]
* OO jDREW
15:41:25 [Harold]
* Python
15:43:02 [Hassan]
MK: named args exist in FLD but there may be dialects other than BLD where names could be meaningful and/or optional
15:43:53 [Hassan]
CSMA: likes the fact named args are not anything special to support - just a convenience
15:44:23 [DaveReynolds]
Harold - I'm not sure CLIPS named argument are compatible with RIF named arguments, I thought you could omit arguements in CLIPS.
15:44:47 [sandro]
MichaelKifer: it would be wrong to say P(b->c a->d) = P(d c) because in a more-useful dialect you'll want to do other things with them.
15:45:09 [Harold]
If you do not support named arguments in your system, then positionalize them using lexical order of the argument names.
15:45:38 [Hassan]
MK: this is a bad idea ... because extending BLD for dialects that treat them differently would be ruled out as extensions of BLD
15:45:46 [Harold]
(that's what I got from Chris' due dilligence)
15:46:22 [AdrianP]
if we don't enforce that RIF users always specifiy explicitly all the signatures of the public functions of a RIF rule set, named args are a good way to to make an "unkown" RIF rule set accessable to new users
15:46:40 [csma]
I would rather have the producer of a RIF document positionalize them, so the burden is onthe one who support them, not on the ones who do not...
15:47:43 [sandro]
Chris: Okay, then: A RIF consumer that does not support named arguments MUST treat them as position arguments in the lexical order of the argument names.
15:47:46 [Hassan]
CSMA: a RIF consumer system that does not support named arguments replace them by positions
15:48:06 [sandro]
csma: How about the producer has to put them in order!
15:48:09 [Hassan]
s/CSMA/ChrisW/
15:49:10 [sandro]
Sandro: csma, the ordering may be significant to users.
15:49:51 [csma]
sandro, agreed; that may be significant if the processor is not an engine, but a browser, an editor etc
15:50:29 [AdrianP]
if we simply skip them and don't implement them in the RIF XML schema it will be very hard for RIF users who need named arguments to extend the RIF schema with named arguments. But if we make them optional in the schema the users can choose if they need them or not
15:50:31 [Harold]
Dave, it would be better to support a special case of named arguments (without 'rests') of any languages (CLIPS, ...) than none at all.
15:51:42 [Hassan]
MK: in BLD there are no declarations so round-tripping is impossible
15:52:44 [csma]
s/processor/producer/
15:52:54 [Hassan]
Axel: if we had the signature as MetaData then it would be possible
15:53:41 [sandro]
PROPOSED: We settled named arguments with: A RIF consumer that does not support named arguments MUST treat them as position arguments in the lexical order of the argument names (as pair of symbol-space name, and lexical representation of that order)
15:53:57 [Hassan]
Jos: Is anyone still opposed to getting rid of named args?
15:54:13 [sandro]
PROPOSED: We settled named arguments with: A RIF consumer that does not support named arguments MUST treat them as positional arguments (of a different predicate) in the lexical order of the argument names (as pair of symbol-space name, and lexical representation of that order)
15:54:47 [sandro]
PROPOSED: We settled named arguments with: A RIF consumer that does not support named arguments MUST treat them as positional arguments (of a different predicate, formed in a defined-by-BLD-way) in the lexical order of the argument names (as pair of symbol-space name, and lexical representation of that order)
15:55:05 [sandro]
PROPOSED: We settled named arguments with: A RIF consumer that does not support named arguments MUST treat them as positional arguments (of a different predicate, formed in a defined-by-BLD-way) in the lexical order of the argument names (sorted as a pair of symbol-space name, and lexical representation of that order)
15:55:07 [Hassan]
ChrisW: it something is "easy" to deal with (e.g., named args) then we should make that explicitly clear and how
15:55:20 [Hassan]
s/it so/if so/
15:55:52 [Hassan]
Jos: what is the syntax for args names
15:56:10 [Hassan]
s/names/names?/
15:56:23 [Hassan]
MK: just names - sequences of chars
15:56:41 [Hassan]
s/chars/unicode chars/
15:56:44 [sandro]
Ah -- so we don't need the symbol-space name.
15:57:02 [Hassan]
Jos: shouldn't names be consts
15:57:25 [Hassan]
s/consts/consts?/
15:58:26 [Hassan]
ChrisW: they would be no problem if they could be optional ...
15:58:37 [csma]
+1
15:58:57 [sandro]
PROPOSED: Removed named arguments. :-)
15:59:02 [Harold]
-1
15:59:05 [josb]
+1
15:59:16 [csma]
PROPOSED: Make named arguments optional
15:59:29 [Hassan]
MK: they do not make sense in BLD because of unique name signatures
15:59:39 [MoZ]
MoZ has joined #rif
15:59:53 [Harold]
Optional?
16:00:04 [sandro]
PROPOSED: We settled named arguments with: A RIF consumer that does not support named arguments MUST treat them as positional arguments (of a different predicate, formed in a stable but implementation-dependent way) in the lexical order of the argument names.
16:00:41 [Harold]
+1
16:00:54 [sandro]
PROPOSED: We keep named arguments, explaining in BLD that: A RIF consumer that does not support named arguments MUST treat them as positional arguments (of a different predicate, formed in a stable but implementation-dependent way) in the lexical order of the argument names.
16:01:06 [Harold]
+1
16:02:06 [AdrianP]
+1 for Sandros proposal (Prova does not support named arguments anyway for efficiency reasons - and where I realy need them, e.g. in inductive logic programming, I simulate them via a meta programing interpreter)
16:03:18 [Harold]
E.g., P(b->?Y a->?X) treated as P'(?X ?Y).
16:03:32 [sandro]
Right.
16:04:32 [sandro]
(note that the second one is P-prime)
16:05:27 [Harold]
Yes, P-prime could be a reserved name for every P.
16:05:49 [Harold]
(as Hassan just mentioned -- for round-tripping)
16:05:59 [Hassan]
ChrisW and CSMA: keep the metadata for translation and recover the original on roundtripping
16:06:47 [sandro]
Sandro: (on board) for P' you can use P__b__a(....)
16:08:44 [sandro]
PROPOSED: We keep named arguments, explaining in BLD that: A RIF consumer that does not support named arguments can implement them, with relative ease, by treated them as positional arguments (of a different predicate, formed in a stable but implementation-dependent way) in the lexical order of the argument names.
16:09:55 [csma]
scribe: Jeff
16:10:04 [csma]
scribenick: JeffP
16:10:37 [JeffP]
ChrisW: let's describe how easy it is in the doc, since MichaelK said it is easy
16:11:08 [AxelPolleres]
How do I rewrite P__a(b->c)
16:11:43 [JeffP]
MichaelK: My only concern is that whether it is be in the main part of a document or in an informative appendix
16:12:06 [JeffP]
ChrisW: it should not only be in examples, it should be in spec
16:14:20 [Harold]
Generally, if the named arguments of P are, lexicographically ordered, aL1, aL2, ..., LaN, then the predicate name is P__aL1__aL2__...__LaN.
16:14:57 [sandro]
Sandro: so, this breaks if you have two translators from RIF to some local language. But that's not a critical use case.
16:16:05 [JeffP]
Sandro: why does it affect comformance, ChrisW?
16:16:39 [JeffP]
(ChrisW has to go)
16:18:30 [sandro]
Sandro: some other Implemtation Techniques we could include: rewriting away existentials and disjunction in conditions.
16:19:16 [JeffP]
csma: we might need to write implementation hints in some of the docs
16:19:43 [sandro]
PROPOSED: We keep named arguments, explaining in BLD that: A RIF consumer that does not support named arguments can implement them, with relative ease, by treated them as positional arguments (of a different predicate, formed in a stable but implementation-dependent way) in the lexical order of the argument names.
16:20:15 [JeffP]
s/treated/treating
16:20:34 [JeffP]
csma: we close issue 44
16:20:41 [sandro]
PROPOSED: We keep named arguments, explaining in BLD that: A RIF consumer that does not support named arguments can implement them, with relative ease, by treating them as positional arguments (of a different predicate, formed in a stable but implementation-dependent way) in the lexical order of the argument names. (Closing ISSUE-44)
16:20:52 [josb]
-0
16:21:02 [josb]
(abstain)
16:21:11 [DaveReynolds]
-0
16:21:15 [GaryHallmark]
-0
16:21:18 [Harold]
+1
16:21:18 [sandro]
RESOLVED: We keep named arguments, explaining in BLD that: A RIF consumer that does not support named arguments can implement them, with relative ease, by treating them as positional arguments (of a different predicate, formed in a stable but implementation-dependent way) in the lexical order of the argument names. (Closing ISSUE-44)
16:22:00 [JeffP]
abstain: josb, DaveR, GaryH
16:23:41 [JeffP]
csma: why can a term be a frame?
16:25:03 [JeffP]
... why did we change from only counting const, var and func as terms?
16:25:33 [JeffP]
MichaelK: once the framework is there, all this becomes possible
16:25:51 [JeffP]
... in the new version, the semantics is simpler in some sense
16:27:37 [sandro]
MichaelKifer: unnesting used to be in there as v1: a[b->c[d->e]] could be rewriten as v2: a[b->c]^c[d->e] no longer the same, because:
16:27:39 [JeffP]
... now a(b->c(d->e)) is no longer the same as a(b->c) ^ c(d->e)
16:27:51 [DaveReynolds]
!!
16:28:28 [JeffP]
... now the whole term c(d->e) is the value, rather than c is the value
16:29:00 [JeffP]
... the new semantics allows reifications
16:29:28 [sandro]
Sandro: Any standard in the F-Logic community on this?
16:29:39 [sandro]
MichaelKifer: No. Slightly different syntaxes for each form.
16:29:44 [JeffP]
csma: what is the consequence when you use frames
16:30:15 [JeffP]
Sandro: how about variables?
16:30:29 [JeffP]
josb: why to make the language more complex?
16:30:45 [JeffP]
Michael: the language is the same
16:30:56 [csma]
csma: what is the consequence when you use frames to represent objects?
16:31:53 [sandro]
MichaelKifer: It used to be that p(a[b->c]) meant the same as p(a)^a[b->c]
16:32:09 [sandro]
Jos: No, frames were terms. This makes the language more complicated.
16:32:26 [JeffP]
jobs: allowing equalities and frames as terms makes the language more complex
16:32:33 [sandro]
MichaelKifer: In this version, p(a[b->c]) introduces a reified term.
16:33:10 [josb]
PROPOSED: equality, frames, subclass, membership are not terms in BLD
16:33:50 [sandro]
MichaelKifer: I don't want unnesting in BLD.
16:34:45 [AxelPolleres]
I tend to agree that reification looks like possibly causing pain...
16:35:50 [JeffP]
Sandro: agree with csma and josb
16:36:16 [JeffP]
csma: this is a major change in BLD
16:36:52 [JeffP]
HaroldB: the reviewers were fine with it
16:37:05 [JeffP]
csma: maybe people overlooked it
16:37:08 [sandro]
Sandro,csma,Jos: The reviewers didn't notice it.
16:37:14 [JeffP]
... we should ask the reviewers
16:37:20 [sandro]
Jos: I thought it was a typo.
16:37:32 [sandro]
Sandro: I am deeply suspicious of reification in here.
16:38:38 [JeffP]
csma: what's DaveR's opition?
16:38:44 [JeffP]
DaveR: I missed that
16:38:48 [AxelPolleres]
Axel: ... I have to think about it, to be honest.
16:38:52 [sandro]
DaveReynolds: I also didn't notice. I assumed the language hadn't changed.
16:39:04 [JeffP]
... the new approach does seem to be a worry for me
16:39:18 [sandro]
MichaelKifer: This reification is in the framework.
16:39:39 [JeffP]
csma: being in the framework is different from being in BLD
16:40:01 [AxelPolleres]
The question to me is more whether we can, with this, "deify" reified statements again by rule application.
16:40:44 [sandro]
on-board: a=(b=c)
16:40:58 [sandro]
MichaelKifer: a = [ some object ]
16:41:22 [JeffP]
MichaelK: a=(b=c) does not entail b=c
16:42:10 [AxelPolleres]
looks like, yes we can "deify" .... john[doe->X] :- f(X). f(a[b->c]).
16:42:28 [sandro]
Sandro: So "=" is both a predicate and a function.
16:43:01 [sandro]
Sandro: I have a problem with <Equal> in the XML being used when no equality is involved.
16:43:28 [sandro]
mkifer: But that's the beauty of reification.
16:44:42 [Harold]
The kind of reification created by frames embedded into other frames as terms (which can no longer be unnested) may be an answer to RDF's problems with 'subject/property/object' reification, and it is a bridge to ISO Common Logic.
16:45:12 [josb]
PROPOSED: equality, frames, subclass, membership are not terms in BLD
16:45:37 [sandro]
Sandro: If we're going to have = be terms, then we should definitely have Ruel be term as well.
16:45:47 [sandro]
mkifer: Yes. I just didn't get that far.
16:46:13 [DaveReynolds]
No. That is not "the" problem with with RDF reification. The RDF Core WG explicitly chose between approach and the one it chose and the decision was based on use cases from community feedback.
16:46:33 [DaveReynolds]
s/between/between this/
16:47:39 [csma]
PROPOSED: equality, frames, subclass, membership are not terms in BLD
16:48:10 [JeffP]
MichaelK: I just want to make it clear, don't have problem disallowing them in BLD
16:49:06 [sandro]
StrawPoll: equality, frames, subclass, membership are not terms in BLD (IE no reification).
16:49:07 [JeffP]
... in BLD many good things don't make much sense
16:51:27 [DaveReynolds]
+1
16:51:42 [sandro]
in favor: 6
16:51:47 [sandro]
(plus DR)
16:51:51 [AxelPolleres]
0
16:51:55 [Hassan]
0
16:52:07 [sandro]
opposed: (wants reification in BLD):
16:52:09 [sandro]
abstain: 4
16:52:16 [sandro]
(MK and Harold abstain).
16:52:35 [sandro]
csma: consensus against reification.
16:54:16 [sandro]
Harold: Do we really want to get rid of nested terms?
16:54:28 [sandro]
Harold: Do we really want to get rid of nested frames?
16:55:44 [JeffP]
MichaelK: it wont be back to the last version due to nesting
16:56:45 [JeffP]
... I agree that BLD should be simple
16:57:08 [JeffP]
... a group is needed to have a dialect extending BLD with reification
16:57:34 [AxelPolleres]
I would like to try for a use case for RDF which uses that feature, i.e. "deifying" reified statements in RDF.
16:57:38 [JeffP]
... with reification the semantics is simpler
17:00:07 [sandro]
PROPOSED: No reification in BLD. This is like WD1, except no nested frames. A change from 18-Feb draft: Equality, frames, subclass, membership are no longer terms.
17:00:42 [AxelPolleres]
p.s.: Gary just clarified that "deify" means "worship as a god"... fits, because I meant to accept a reified statement as truth.
17:01:56 [sandro]
Harold: Implementation Hint -- producers can pre-flatten nested frames.
17:02:00 [DaveReynolds]
Axel - the choice of RDF to use reification for so called "statings" rather than "statements" was quite deliberate, if you want to reverse you'd need to address the use cases that originally motivated that choice.
17:02:08 [sandro]
Mkifer: No - producers will know how to do it.
17:02:26 [sandro]
abstain: hassan, mkifer
17:02:35 [sandro]
RESOLVED: No reification in BLD. This is like WD1, except no nested frames. A change from 18-Feb draft: Equality, frames, subclass, membership are no longer terms.
17:02:42 [JeffP]
2 abstain
17:02:52 [sandro]
ADJOURN.
17:02:59 [sandro]
reconvene at 9am.
17:03:06 [DaveReynolds]
bye - have a good evening
17:03:12 [JeffP]
bye, Dave
17:03:12 [Zakim]
-DaveReynolds
17:03:14 [Zakim]
-Meeting_Room
17:03:15 [Zakim]
Team_(rif)15:07Z has ended
17:03:16 [Zakim]
Attendees were Meeting_Room, +44.145.441.aaaa, DaveReynolds
17:03:20 [sandro]
Ciao, DaveReynolds !
17:03:31 [Harold]
Ciao, Dave
17:07:12 [sandro]
http://maps.google.com/maps?ie=UTF-8&oe=utf-8&rls=com.ubuntu:en-US:official&client=firefox-a&um=1&q=51+rue+du+commerce,+75015&near=Paris,+France&fb=1&cid=0,0,5730491396441972763&sa=X&oi=local_result&resnum=1&ct=image
17:19:03 [csma]
Le Café du Commerce du 15ème
17:19:15 [csma]
51, rue du Commerce 75015
17:19:15 [csma]
Tel: 01-45-75-03-27
17:19:15 [csma]
17:19:15 [csma]
Avenue Emile Zola
17:34:13 [Zakim]
Zakim has left #rif
17:42:52 [sandro]
RRSAgent, pointer?
17:42:52 [RRSAgent]
See http://www.w3.org/2008/02/21-rif-irc#T17-42-52
17:42:57 [sandro]
RRSAgent, make record public
17:54:03 [MoZ]
MoZ has joined #rif