See also: IRC log
<Harold> Hi Chris, I just saw your email.
<Harold> Further down in my email, I wrote:HB> Indeed, using the Prolog-like notation s/a for an s of arity a,
<Harold> HB> s/n{1->t_1, …, i->t_i, …, n->t_n} doesn’t unify s/i{1->t_1, …, i->t_i}
<Harold> HB> and with this ‘locally-closed-slot’ semantics imposed by s/n and s/i
<Harold> HB> s/n(t_1, …, t_i, …, t_n) would no longer unify s/i(t_1, …, t_i).
<ChrisW> hmmm - i missed it somehow
<ChrisW> ok
<ChrisW> thanks for pointing it out
<ChrisW> so then you are ok with positional->keyword mapping + signatures
<ChrisW> Agenda is: http://lists.w3.org/Archives/Public/public-rif-wg/2007Jan/0000.html
<ChrisW> hold on
<ChrisW> scribenick: Deborah_Nichols
<ChrisW> Scribe: Deborah Nichols
<LeoraMorgenstern> I'm not on the phone yet (some connection problems)
<LeoraMorgenstern> but just wanted to say that I have just sent out the draft minutes
<LeoraMorgenstern> for the December 19 meeting
<ChrisW> ok leora
<csma> yes, we did
Minutes of 12/26 meeting will be approved next week.
All admin actions are continued.
No additions to the agenda.
<Allen> no
Sandro has an open action to set up the registration.
from Chris: ISO Common Logic has hit the final deadline for comments, and the document is in its final form.
We will not come to a resolution today.
First discussion point: there will be elements of any RIF dialect that will be shared, so it makes sense to have a library -- pieces of the specification -- of components that can be used across dialects, e.g., that a rule has a head and body, or constraints.
We need to create a specification of what a dialect is, etc., to help those who are designing their own dialects.
So we propose a RIF-Arch (Architecture) document to do that.
<ChrisW> http://www.w3.org/2005/rules/wg/wiki/Arch
URL to a preliminary document containing examples of the kinds of things that RIF-Arch should cover: http://www.w3.org/2005/rules/wg/wiki/Arch
csma: Should also define syntactic as well as semantic components, e.g., what are the normative definitions for, e.g., conjunction, etc.
Dave Reynolds: Would cmsa include in syntactic elements things like functions, operators, etc.?
Yes, those things would be available for reuse by dialect creators.
ChrisW: In designing RIF Core, we recognize that there are elements in the Core that can be reused.
csma: If you create a dialect that extends the Core, then you can reuse components from the Core as well as adding your own.
Dave: Are you talking about a starter library or a registry?
<FrankMcCabe> +q
<FrankMcCabe> -q
csma: When we define Core, it will be as part of a library.
<sandro> I think of it more like a registry
<sandro> seriously.
ChrisW: The Arch document will not be the sum total of the dialects.
Sandro: But my understanding is that the document would be the union of all the standard dialects.
<csma> frank, it is q+/q-
Harold: Proposes we might
automate the transition from a modular version composed of
dialects to a flat version.
... You might want one Arch document where you can find all the
features in one place.
<FrankMcCabe> +q
csma: Might not be easy or
possible to construct such a list of features from the modular
components, because the style might be different in each
document.
... Might be necessary to separately enter the features of a
new dialect into the Arch document.
Sandro: Prefers a pointer mechansim, rather than copying text; then add additional explanation if needed in Arch document.
Harold: It seems we are talking about a system of dialects that may be siblings, and there may be inconsistencies. So really there's a network of features.
Frank: At first thought csma was
referring to something called "Architectural Principles" (in
architecture circles). Such AP documents are not an enumeration
of actual features but a statement of general principles for
developing features.
... It seems to be just busywork to copy over one's dialect's
features into a separate document.
Sandro: If multiple documents use the same 'negation', then it should be defined the same way in one place.
Frank: Why not simply in the
dialect?
... Proposes we postpone the problem till we're actually facing
it..
Sandro: We can list the components in the actual dialects or in an archicture spec.
csma: The difference between those options is in the way the components are described. In an arch spec, there can be a consistent description.
<Hassan> http://www.w3.org/2005/rules/wg/wiki/BottomUpClassification
Frank: Is this a matter of enforcing some single style -- but participants have different styles.
Hassan: Sees the proposal as primarily to be able to share components.
Dave: Makes sense to me to have a
starter library. But to have a registry of all components of
all dialects goes beyond that.
... Esp. if it requires all components to be normatively
described to be registered in a central architecture
document.
csma: I think both Sandro and I meant this as a starter library.
cmsa: Designers of new dialects then add their new components to the starter library.
Dave: But the latter sounds like a universal registry of all dialect components.
csma: What would be the problem with designers of new features adding their components to the arch document?
Dave: Two potential problems: When you have too many new features, then reuse goes down, and/or it may be a burden on the designer to register.
<Hassan> Why would adding a dialect be a problem? It would tend to defeat *interchange* (granted) so the reuse is an *encouragement* to interchange!
csma: We don't forbid people to develop their own components. But we want to provide a place for people to look for reusable components.
ChrisW: 2 choices: 1. specify the document in separate documents; 2. specify the dialects in one document together. Or both.
Sandro: But that doesn't cover orthogonal dialects. Those fit better into a component library than into a specification document; e.g., roundtripping components.
<Zakim> sandro, you wanted to say I'm now leaning against a registry or starter library
ChrisW: Original proposal was a specification document, didn't cover a component library.
<scribe> New subtopic: Slots and Constraints
ChrisW: Summary. At f2f, Hassan
sent a message to unify the keyword based approach with
positional approach, by mapping positional arguments into
slotted or keyword arguments.
... Harold found a problem with this because you can get
strange unifications. Harold proposed reverse mapping from
keyword to positional.
... But people found problems with that due to strange
non-unifications.
<scribe> ...New proposal was to add signatures to the keyword-to-positional mapping approach. And Harold is okay with that.
Michael: There's a problem with
this proposal because it is completely syntactic. It's not
clear that it captures relational notation, and it definitely
doesn't capture F-logic. Michael is working on a document to
show this and to explain what the issues are, which should be
ready tonight.
... Briefly, in all cases, slots are functions; but, what
additional semantics are attached to functions? At least three
possibilities: slot notation, psi-notation, and ?? In all
cases, those are functions, but from different things to
different things, so they are semantically not equal.
... Maybe we should not include 'slot' in the core, and let it
be developed in the dialects. He is opposed to providing a
syntactic component that can be given different semantics.
Three: relational, psi-terms, and one from F-logic.
And in addition, there may be multiple kinds of statements you want to make with slots, as in F-logic.
ChrisW: What do you understand by "slot", Michael?
[need to get from Michael]
Chris
ChrisW: Acknowledges that Michael and Christian may mean different things by 'slot'.
<ChrisW> ^ChrisW^Michael^
Michael: There is a way to translate from relational into F-logic notation. Not sure about the other way around. Haven't investigated with psi-terms.
<ChrisW> ^Christian^Harold
Michael: The question is whether we include multiple definitions of slot in the core or leave them to be developed in dialects.
csma: Is there a problem including one definition of slot in the Core?
Michael: There should be a good reason for selecting only one for the Core. Would not want to leave it as syntax open to multiple interpretations.
Hassan: Don't understand what the
problem issue. Proposed CLP to de-sugar anything you want away
-- any syntax -- into constraints. This should allow you to
write down clearly what the semantics is.
... Don't understand why we're using a syntactic trick when it
isn't needed.
ChrisW: To clarify: Hassan raised 2 points, one to Michael and one to Harold. Michael isn't arguing against using CLP -- Hassan knows that. 2nd point to Harold was, why are we using a 'syntactic trick' when we don't need to?
Hassan: On 2nd point, wants us not to use a syntactic trick - either put a slotted syntax in the Core with a clear specification, or leave it to be defined in dialects outside the Core.
Michael: Your point is that we are defining a syntax in the Core, and a syntax is supposed to have semantics. But due to an ambiguity in the semantics of slot, we need to define at least three different kinds of slot.
Hassan: Why can't we take one syntax and give it three different semantics?
ChrisW: But some dialects may need more than one of the three interpretations of slot -- that would be impossible if the same syntax is used for the three interpretations.
csma: If you agree there can be 3+ types of semantics, then why not have different syntax with the different semantics?
Michael: Are you saying build in 3 different syntax components, or 1 component with 3 interpretations?
Hassan: The latter.
csma: But why do you want to have only 1 syntax for 3 different semantics?
ChrisW: The reason you might *not* want to do that is when you want to mix them.
Michael: It's also confusing, as though we are giving one language with three interpretations. Confusing.
Hassan: It
... It is not a language but a language schema.
ChrisW: Do you agree that if a dialect needs more than one sense of slot, then we need more than one syntax?
Hassan: Would like to see such a use case.
Michael: E.g., RuleML has two
kinds of slots. Also, the Flora system, which has only F-logic
syntax, some people have requested having also the relational
syntax. That is an example from user experience.
... Flora has positional predicates as well, but people wanted
also to have slots where positions don't matter. Flora doesn't
support that, but its users want it -- that is the use
case.
<Hassan> I second Gerd's proposal to survey what sorts of slots we really need in actual would-be RIF languages
Gerd proposes that we should use use cases to identify the most important use of slots, and include that in the Core.
Harold: [offers another proposal for how to cover other interpretations of slot.]
Gerd: Christian's statement on issue 12 is stronger than Gerd understands RIF Charter to have committed.
csma: We don't know what the requirements are on a standard semantic web language, so wants not to commit ourselves to that.
Frank: But seems to say that RIF will do no work towards making a standard SW rule language. If that's true, let's make it clear.
<ChrisW> ^Frank^Dave
csma: There are things we will do, such as enabling RIF dialects to handle RIF and OWL.
<ChrisW> ^Gerd^Dave
csma: His point is not to commit to something till we know what we're committing to.
Sandro: Sounds like Dave has a notion of what a SW rule language would be. Sandro doesn't really see what it would be.
ChrisW: Agrees with Sandro that there is nothing like a consensus on what SW rule language would be.
Dave: But you can read csma's proposed wording as though *all* of the dialects would meet some minimum requirement for being a SW RL.
^RL^rule language
Dave: My concern is that people would make assumptions about what any dialect would do for them, when it wouldn't.
Sandro: Should we qualify the assertion to say that the use of RIF as a SW rule language is a side effect only?
ChrisW: Dave has a very definite idea of what a SW rule language should be and do.
csma: "Also the design goal of each dialect is for rule interchange; some of them may also end up being useful as SW rule languages" -- is that acceptable?
Dave: Prefers the text that says RIF is not doing work on SW rule language.
ChrisW: Doesn't want to preclude RIF from doing work on SW rule language.
csma: Removed "primary" from the design goal of dialects, so as not to imply there was a commitment to developing dialects as SW rule languages.
ChrisW: We will continue discussion on the above point in email and next week.
Next sub-topic: UCR document
<ChrisW> ACTION: allen to add new definition of covers to UCR [recorded in http://www.w3.org/2007/01/02-rif-minutes.html#action01]
<rifbot> Created ACTION-205 - Add new definition of covers to UCR [on Allen Ginsberg - due 2007-01-09].
Allen: The coverage issue has
been addressed, and then the document is ready to sent
out.
... One more item related to Use Case 1 needs to be
addressed.
csma will look at that use case.
ChrisW reviewed the UCR action list.
ChrisW: Proposed rule examples were all deferred till we finish the Core.
^sent^send
<GerdWagner> -GerdWagner
No updates on RIFRAF
This is scribe.perl Revision: 1.127 of Date: 2005/08/16 15:12:03 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/of a dialect/composed of dialects/ Succeeded: s/tenbd/tend/ Succeeded: s/additional/addition/ Succeeded: s/csma/Hassan/ Found ScribeNick: Deborah_Nichols Found Scribe: Deborah Nichols Default Present: Hassan_Ait-Kaci, FrankMcCabe, csma, Deborah_Nichols, ChrisW, Dave_Reynolds, Sandro, Allen_Ginsberg, Leora_Morgenstern, Harold_Boley, Gary_Hallmark, Michael_Kifer, Mike_Dean, Gerd_Wagner Present: Hassan_Ait-Kaci FrankMcCabe csma Deborah_Nichols ChrisW Dave_Reynolds Sandro Allen_Ginsberg Leora_Morgenstern Harold_Boley Gary_Hallmark Michael_Kifer Mike_Dean Gerd_Wagner Regrets: FrançoisBry IgorMozetic PaulaLaviniaPatranjan DavidHirtle MohamedZergaoui JosDeBruijn Agenda: http://lists.w3.org/Archives/Public/public-rif-wg/2007Jan/0000.html Got date from IRC log name: 2 Jan 2007 Guessing minutes URL: http://www.w3.org/2007/01/02-rif-minutes.html People with action items: allen[End of scribe.perl diagnostic output]