Admin

<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2007Dec/att-0087/2007-12-11-rif-minutes.html

ChrisW: Above are the minutes from Dec 11 meeting. Any objections? ... none

<ChrisW> RESOLVED: Accept minutes of Dec 11 telecon

<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2008Jan/att-0000/18-rif-irc.html

ChrisW: Above are the minutes from Dec 18. Any objections? ... none

<ChrisW> RESOLVED: Accept minutes of Dec 18 telecon

ChrisW: There is now a new wiki page for posting regrets

<csma> http://www.w3.org/2005/rules/wiki/TeleconRegrets

ChrisW: There will soon be a link to it on the new home page
... Use this page from now on. It will have the regrets for all the meetings. If the meeting you are adding regrets for is not there yet, just add a line to the page for that meeting.
... Note that the official record of regrets is, and has always been, the minutes of the meeting

Liason

ChrisW: Any news from liasons?

JosB: The RIF-OWL task force will have the first telecon meeting tomorrow, and we have been discussing a proposal

ChrisW: When do you tihnk you'll have something to show the working group?

JosB: We should have something in two weeks, but it won't be final yet.

ChrisW: Responses to Peter F. Patel-Schneider's comments on BLD and SWC are on the main page.

<ChrisW> http://www.w3.org/2005/rules/wg/wiki/Response_to_PPS1

<ChrisW> http://www.w3.org/2005/rules/wg/wiki/Response_to_PPS2

ChrisW: I think the 1st response is finished.
... people can have a few days to look at it and then, unless someone objects, we'll send that response later this week

ChrisW: I don't think the 2nd response is ready yet

ChrisW: Any other liason news? ... none

BLD & Core

Issue 43 (classification)

ChrisW: I posted proposals for resolution of issues 41 and 43 to the mailing list

<ChrisW> PROPOSED: Close Issue-43 by including in BLD subclass formulae of the form a ## b. In the RDF compatibility document, ## and rdfs:subClassOf will be connected appropriately, i.e. whenever a ## b holds, a rdfs:subClassOf b is required to hold.

ChrisW: The change here is that there is a formal relationship between RDF and RIF subclass relations
... any discussion on this?

ChrisW: vote on IRC

<sandro> +1

<csma> -0

<DaveReynolds> +0

<IgorMozetic> +1

<josb> +0

<Hassan> +0

<PaulVincent> +0

<LeoraMorgenstern> +1

<mdean> +1

<Harold> +1

<AxelPolleres> +1

<MichaelKifer> +1

<AxelPolleres> What is the diff between +0 and -0, btw?

Sandro: The +/- on 0 indicates whether you feel positively or negatively about it

<sandro> repeating: <ChrisW> PROPOSED: Close Issue-43 by including in BLD subclass formulae of the form a ## b. In the RDF compatibility document, ## and rdfs:subClassOf will be connected appropriately, i.e. whenever a ## b holds, a rdfs:subClassOf b is required to hold.

<ChrisW> RESOLVED: Close Issue-43 by including in BLD subclass formulae of the form a ## b. In the RDF compatibility document, ## and rdfs:subClassOf will be connected appropriately, i.e. whenever a ## b holds, a rdfs:subClassOf b is required to hold.

Issue 41 (membership)

<ChrisW> PROPOSED: Close Issue-41 by including in BLD membership formulae of the form c # a. In the RDF compatibility document, # and rdf:type will be connected appropriately, i.e. a # b holds iff a rdf:type b holds.

ChrisW: Any disucssion about this?

Christian: I wonder if this resolution would impact the way membership is handled with XML documents or XML schema data models or other data models
... ...because it is equivalent to rdf:type

ChrisW: Only use it if semantics is appropriate for your case

Christian: We want it to be used by all RIF users, not just in the case of RDF documents
... I don't know whether there is an impact; I think we need to consider the question. For example, how would it impact Dave's use case posted below?

http://lists.w3.org/Archives/Public/public-rif-wg/2007Nov/0077.html

JosB: This relation is intended for use with different data models, not just RDF
... the relation as defined may work in the case of object oriented XML
... for general XML it would not work, because membership is different from XML schema type

<Hassan> I understand the same as ChrisW ...

Christian: I thought we didn't give semantics to RIF membership, we just said it is equivalent to rdf:type

ChrisW: The semantics for RIF membership are given in the BLD document (it is not just defined as equivalent to rdf:type)

JosB: The equivalence with RDF holds when you are talking about RIF-RDF combinations
... it would be possible to define a weaker kind of correspondence
... if you don't combine it with RDF (no external RDF graph, no RDF vocabulary), then you don't inherit any of the RDF semantics

ChrisW: BLD semantics stands by itself

Christian: From the interchange point of view: between an RDF rule engine and a C++ rule engine
... if they have the same semantics as RDF:type, it is OK, but if not it will make interchange difficult
... maybe we will need to have different membership relations for different kind of data models

Hassan: I don't think RIF is defined to be compatible with RDF; it just happens to be in this case
... we don't need different relations for different data models, but rather interfacing will need to be done when using data models with a membership relation with different semantics

ChrisW: This is the membership relation used by basic logic dialects

<Harold> Jos, what about OWL compatibility? How will "a # b holds iff a rdf:type b" generalize to DL-inferred OWL memberships?

<josb> Harold, this will depend on how OWL compatibility will be defined in the end; see also http://www.w3.org/2005/rules/wg/wiki/SWC/OWL-Compatibility

<Harold> Jos, great, I guess the RIF-OWL task force is looking into this?

<josb> Harold. correct

Christian: The PRD dialect will also need a membership relation. If it makes sense to have the same one as BLD and to have it in Core, then that would be preferable

JosB: RIF membership is not the same as the rdf:type construct
... there is a correspondence, but it is not the same
... also, if there are different type of membership relations, you will have to encode them differently in RIF

ChrisW: The WG seems to want to have this one particular relation in the language

ChrisW: Any other discussion?
... will anyone object to this proposed resolution? ... (no one objects)

<ChrisW> PROPOSED: Close Issue-41 by including in BLD membership formulae of the form c # a. In the RDF compatibility document, # and rdf:type will be connected appropriately, i.e. a # b holds iff a rdf:type b holds.

ChrisW: Vote on IRC

<Hassan> +0

<sandro> +1

<IgorMozetic> +1

<Harold> +1

<AxelPolleres> +1

<DaveReynolds> +0

<csma> 0

<MichaelKifer> +1

<LeoraMorgenstern> +1

<mdean> +0

<josb> +0

<PaulVincent> =0

<GaryHallmark> +1

ChrisW: 7 for, 5 abstain

<ChrisW> RESOLVED: Close Issue-41 by including in BLD membership formulae of the form c # a. In the RDF compatibility document, # and rdf:type will be connected appropriately, i.e. a # b holds iff a rdf:type b holds.

ChrisW: A few people requested that we also have a resolution that these features will not be in the core language

<ChrisW> PROPOSED: Core does not have membership and classification.

ChrisW: Any discussion on this? Does anyone object?

Christian: The question is if we want to have the same membership and classification in PRD, then I think it makes sense to have them in Core

ChrisW: Do you think that needs further study before we pass a resolution?

Christian: I'm not sure

JosB: Not having membership and classification in Core, does not preclude having them in PRD

Christian: Right, but if everyone needs them for rule interchange it would make sense to have them in Core

ChrisW: Christian, do you want to postpone this vote?

<IgorMozetic> I vote for vote!

<josb> we can always overturn a resolution if we have more info

Christian: I just wanted to raise this point, and see what others think.

HaroldB: Christian, do you think you will need one of these things (membership, classification) in PRD?

Christian: In PRD we will need a way to check class membership

ChrisW: Does anyone object to having membership in Core?

<josb> yes

<DaveReynolds> probably :-)

<ChrisW> PROPOSED: Core does not have membership and classification.

Sandro: I think no one wants these relations in Core, and no one objects to having them in Core, Is that right?

ChrisW: People don't feel strongly about it

Sandro: I don't think we are ready to decide this yet

<Hassan> +1 with sandro - what's the rush before we have used the RIF for real?

Sandro: I am in favor of having them in core if every dialect needs them

<PaulVincent> What rule language classes (dialects) would NOT have membership / classification? I wonder

<josb> Paul, all rule langs based on rdf or owl do not need # or ##

<GaryHallmark> I can see them in Core bodies, but not in heads, but that seems complex to specify

<Hassan> Paul: What about Prolog?

ChrisW: Ok, we will postpone this vote, and we need to open an issue on it

<ChrisW> ACTION: christian to open an issue on whether membership and classification are in core [recorded in http://www.w3.org/2008/01/08-rif-minutes.html#action01]

<trackbot-ng> Created ACTION-399 - Open an issue on whether membership and classification are in core [on Christian de Sainte Marie - due 2008-01-15].

Issue 44 (named arguments uniterm)

<ChrisW> http://www.w3.org/2005/rules/wg/track/issues/44

ChrisW: Any discussion on this issue?

Christian: What is the purpose of having two different slotted notations: frame and named argument uniterms?

<AxelPolleres> well, jos now we defined # as syntactic sugar for rdf:type, so in presentation syntax it might be more convenient (like "a" in turtle/n3), but you are right it is not NEEDED.

ChrisW: Named argument uniterms do not implicitly create an object, so if you're using a relational semantics you don't have to create any other object

<josb> +1

Christian: If you deal with relational semantics, why do you need the name for the arguments?
... why not use positional uniterms when you have relational semantics?

ChrisW: If you have a predicate that has a lot of arguments and you don't want to specify all of them

MichaelK: With named arguments, you have to specify all of them, but you don't need to remember their order

<GaryHallmark> let's simplify things and drop slotted uniterms

<josb> +1 agree with Gary

<DaveReynolds> +1 to Gary

<Harold> Let's look at this CLIPS example:

<Harold> (deffacts trouble_shooting

<Harold> (car_problem (name ignition_key) (status on))

<Harold> (car_problem (name engine) (status wont_start))

<Harold> (car_problem (name headlights) (status work))

<Harold> )

<Harold> http://en.wikipedia.org/wiki/CLIPS

MichaelK: With positional arguments, if all are not there, it's not clear which is missing

Christian: HaroldB, I do not understand the example you posted above

<DaveReynolds> Harold - aren't these slots, not named arguments in uniterms?

HaroldB: This example shows named arguments, where the order does not matter, it is a convenience

Christian: It constructs objects

HaroldB: But there is no oid (object id)

Hassan: We have decided to distinguish between frames and terms in BLD, but they are basically the same thing

<Harold> Dave, do you mean slots in frames vs. named arguments in uniterms?

<DaveReynolds> Harold, yes.

Christian: We have proposed semantics for frames and named argument uniterms. do you think we could choose just one of these?

Hassan: Yes, we could choose the best compromise that can express most things
... both frames and slotted terms are just labelled graphs

ChrisW: The main difference between these two is the oid (object id) issue. How important is that?

<Harold> Then, I think it is good to have both.

HaroldB: Without the oid (object id), we cannot apply the function, therefore we need named argument uniterms

Christian: Re: clips example above. if my ignition key is on and engine won't start and headlights don't work. wouldn't there need to be an object here?

<ChrisW> ack

HaroldB: Yes, for the troubleshooting case. But the 3 inner uniterms would be anonymous

MichaelK: I think we are getting sidetracked. We are not defining a language, we are defining a framework
... the reason that we have frames, positional terms, and named argument terms, is that we will have dialects that use these styles, and we want to facilitate interchange

ChrisW: Any other discussion?

<IgorMozetic> +1 for mk

<josb> I prefer to not have them, but can live with mk's compromise (like the membership and subclass compromises)

<Hassan> Same opinion as josb (i.e., do not care either way, leaning toward the simpler - i.e., not having them)

DaveReynolds: About what MichaelK said, do we have a use case that requires named uniterms?

<ChrisW> OO JDREW & CLIPS

DaveReynolds: Those are production dialects

ChrisW: Are there logic languages that have these?

MichaelK: OO jdrew is a logical language

<Harold> We have a nice transition: positional uniterms -add slots-> slotted uniterms (with named arguments) --add oids-> slotted frames

DaveReynolds: What do you mean by a transition?

<AxelPolleres> slotted frames are definitly NOT an "extension" of sloted uniterms...

<AxelPolleres> ... I wonder a bit about what Harold means here.

HaroldB: RIF in an interchange format, so we need to accomodate CLIPS

DaveReynolds: That would be PRD dialect, not BLD

<AxelPolleres> anyway, I think the abstract model definition accomodated for all, so it wouldn't need be a problem.

<LeoraMorgenstern> I think we should have it ...

ChrisW: Does anyone feel strongly that we shouldn't have named argument uniterms?

<LeoraMorgenstern> I didn't realize we were being polled yet

<ChrisW> STRAW POLL: Having named uniterms in BLD

<Hassan> -0.00001

<DaveReynolds> - 0.5

<Harold> +1

<MichaelKifer> +1

<LeoraMorgenstern> +1

<AxelPolleres> +0.7

<IgorMozetic> +0.8

<sandro> +0.75

<mdean> -0.5

<PaulVincent> -0

<josb> +0

<LeoraMorgenstern> If only we could vote in the primaries this way.

<GaryHallmark> -0.5

ChrisW: I would like to know who would object to having named argument uniterms in BLD

<csma> -0

<sandro> +0

<josb> +0

<GaryHallmark> -0

<Hassan> -0

<PaulVincent> -0

<AxelPolleres> We have a semantics for it, it is clear what it means, no reason to delete it from BLD...

<csma> I change my -0 for a -0,5

<csma> based on Dave's interpretation of -0,5

<AxelPolleres> I obviously wouldn't like it in core.

<Harold> So it's again a question of core vs. bld.

<josb> -1 for having it in Core

DaveReynolds: -0.5 means I might object, but I am not sure yet

<GaryHallmark> Harold, I think your CLIPS example does in fact have OIDs

<GaryHallmark> Harold, look at http://www.ghg.net/clips/download/documentation/bpg.pdf page 206 for example

<Harold> Gary, "in fact"? Do you mean there will be three oids generated and returned to the user? Generating oids can be seen as transiting from slotted uniterms to slotted frames.

<GaryHallmark> Harold, the first assert creates fact-id 1, the second creates fact-id 2, etc. and these fact-ids may be used later to retrieve slot values

<Harold> Gary, Thanks.

Issue 47 (equality)

<ChrisW> http://www.w3.org/2005/rules/wg/track/issues/47

<AxelPolleres> yes, core should be datalog w/o equality, (as discussed/suggested sometimes), right?

<AxelPolleres> .... (the yes was to harold)

ChrisW: Equality is currently in BLD semantics, but it is difficult to implement.

MichaelK: Equality is a useful thing that is hard to implement, but can be partially implemented easily

Sandro: This came up during the conformance discussion. We want it to be possible to completely implement RIF. We want conformant implementations.

<IgorMozetic> +1 for sandro

<Harold> Axel, Jos, if we were to have no Clips-like slotted uniterms (with named arguments) in core, there would be an increased risk that prd would not be built on core (and perhaps not on bld, because that might be too much).

MichaelK: (re: Sandro's concern about my comment about performance of a full implementation of equality) It won't slow down the usual cases

Sandro: Ok, that is not so bad

<sandro> (So, I understand MichaelKifer to be saying that he (Flora) can implement BLD. Some kinds of equality will be slow to handle, some will be fine, and all can be done.)

<DaveReynolds> I'm confused by the term "implementation" here, implementing RIF means implementing a translator, not a rule engine

MichaelK: It will make a mess out of the language if we try to specify the easily implemented cases at the language level
... e.g. Ground equality - you cannot really specify this cleanly in the language (he gave a 2nd example also)

ChrisW: Does anyone in the group feel strongly that we should remove equality from BLD because it is hard to implement efficiently in its full generality?

<AxelPolleres> No way to remove it from BLD, I see BLD rather as a dialect which CAN be implemented, but not which MOST rule engines could cope with.

<DaveReynolds> Seems preferable to postpone to a higher dialect

Sandro: Process note: the usual way this works is that during candidate recommendation we have to provide evidence that there are at least two complete implementations

ChrisW: I'm not sure how strict a requirement that is; OWL didn't have complete implementations

<AxelPolleres> I see BLD more as a "repository" which subdialects/profiles can draw the clear definitions from.

AxelP: I see BLD as the semantic framework for logic based definitions of rule languages. It doesn't mean that any single rule system needs to implement every feature in BLD

ChrisW: But BLD is the ~basic~ logic dialect

<sandro> Axel argues for BLD as UNION. I beleive it should be the INTERSECTION.

<Harold> Axel, I agree, this was also Michael's and my *interchange format* argument.

<AxelPolleres> Harold, yes!

<AxelPolleres> ... I get it now. We will not implement full BLD, but it is useful to have it semantically defined within RIF.

<sandro> straw-proposed: remove equality from BLD

ChrisW: Is there anyone who is even leaning towards wanting to remove equality from BLD?

Christian: I am leaning in that direction, but less than I was before

<AxelPolleres> s/it defined/equality defined/

<sandro> -0 keep equality in BLD

<AxelPolleres> We need a core profile or subdialect or whatever you want to call it.

<Harold> Axel, I agree, although we could run full BLD in a FOL porver with Equality.

<sandro> er -- that is, I want to keep equality in BLD.

<ChrisW> STRAW POLL: closing issue 47 without action

<sandro> +1

<josb> +1

<Harold> +1

<LeoraMorgenstern> +1

<DaveReynolds> -0

<IgorMozetic> +1

<MichaelKifer> +1

<AxelPolleres> +1, with still claiming for a CORE profile/subdialect

<mdean> +1

<csma> =0

<GaryHallmark> +1 to keep equality in bld

ChrisW: We will try to have a resolution on this at next week's telecon

<AxelPolleres> Did we now raise/record an issue?

AOB

<ChrisW> gary - can you scribe next week?

<GaryHallmark chrisw, ok

<ChrisW> thanks!

ChrisW: Any objections to adjourning?... no objections

<PaulVincent> bye