See also: IRC log
Chair: Minutes from the 12/19/06 meeting have been sent out by Leora and will be approved next week.
Chair: All administrative actions are continued.
Chair invited additions to the agenda; none was proposed.
Chair: Sandro has an open action to set up the registration for F2F5, to be held at MITRE in McLean, Virginia, USA, on Feb. 26-28, 2007.
ChrisW: The ISO Common Logic specification has passed the final deadline for comments, and the document is in final form.
Chair: Today we will discuss some technical design issues, but without expecting to come to a resolution, due to limited attendance.
Chair: First discussion point: We propose a RIF-Arch (Architecture) document to create a specification of what a dialect is, to help those who are designing their own dialects. And since there will be elements of any RIF dialect that will be shared, it makes sense to have a library of components -- that is, pieces of the specification -- that can be used across dialects, such as, head and body, constraints, etc. A preliminary document containing the kinds of things that RIF-Arch should cover is at this URL: http://www.w3.org/2005/rules/wg/wiki/Arch
csma: It should also define syntactic as well as semantic components, that is, what the normative definitions are for, e.g., conjunction, disjunction, etc.
DaveReynolds: Would that include in syntactic elements things like functions, operators, etc.?
csma: Yes, since those things would be available for reuse by dialect creators.
Chair: In designing the 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 for all components?
csma: When we define the Core, it will be as part of a library.
sandro I think of it more like a registry.
ChrisW: The Architecture 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.
Harold: Proposes that we might automate the transition from a modular version composed of dialects to a flat version. You might want one Architecture document where you can find all the features in one place.
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. It might be necessary to separately enter the features of a new dialect into the Architecture document.
Sandro: Prefers a pointer mechanism, rather than copying text over; then add additional explanation,if needed, in the Architecture document.
Harold: It seems we are talking about a system of dialects that may contain incompatible siblings, and there may be inconsistencies. So really there's a network of features.
Frank: At first I thought Christian 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 [Architecture] document.
Sandro: But 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? Propose that 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 architecture spec, there can be a consistent description.
Frank: Is this a matter of enforcing some single style -- but participants have different styles.
Hassan: Sees the proposal's purpose as primarily to be able to share components. Hassan has a concern about how components will be classified in the RIF-Arch document. See http://www.w3.org/2005/rules/wg/wiki/BottomUpClassification.
Dave: Makes sense to me to have a starter library. But to have a registry of all components of dialects goes beyond that, esp. if it requires all components to be normatively described in order to be registered in a central architecture document.
csma: I think both Sandro and I meant this as a starter library. Designers of new dialects 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 architecture 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.
Chair: These are the choices: 1. specify the dialects 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
Chair: Our original proposal was a specification document; it didn't cover a component library.
Chair: Summary. At F2F4, Hassan sent a message proposing to unify the keyword-based approach to slots with the positional approach, by mapping positional arguments into slotted or keyword arguments. Harold found a problem with that because you can get strange unifications. Harold proposed a reverse mapping from keyword to positional representation. But people found problems with that due to strange non-unifications. The newest proposal was to add signatures to the keyword-to-positional mapping approach. And it seems 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 in some detail (which should be ready tonight). Briefly, in all cases, slots are functions; but, what additional semantics are attached to functions? There are at least three possibilities for slot semantics: relational, psi-terms, and one from F-logic. In all cases, those are functions, but from different things to different things, so they are semantically not equal. In addition, there may be multiple kinds of statements one wants to make with slots, as in F-logic. Therefore, maybe the RIF should not include 'slot' in the Core, and let it be developed in the dialects instead. Michael is opposed to providing a Core syntactic component that can be given different semantics.
Chair: What do you understand by "slot", Michael?
[scribe: need to get from Michael]
Michael: Acknowledges that Michael and Harold may mean different things by 'slot'.
Michael: There is a way to translate from relational into F-logic notation. Not sure about the other way around. Haven't investigated translations with psi-terms.
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 [only] one definition of slot in the Core?
Michael: There should be a good reason for selecting only one for the Core. We would not want to leave it as syntax open to multiple interpretations.
Hassan: Doesn't understand what the problem is. He proposed CLP to de-sugar anything you want away -- from any syntax -- into constraints. This should allow you to write down clearly what the semantics is. Hassan doesn't understand why we're using a syntactic trick when it isn't needed.
Chair: To clarify: Hassan raised two points, one to Michael and one to Harold. In response to the first, Michael isn't arguing against using CLP. The second question, to Harold, was, why are we using a 'syntactic trick' when we don't need to?
Hassan: Hassan acknowledges that Michael isn't opposed to CLP. On the second point, Hassan 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: Hassan's 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?
Chair: 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 that 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?
Chair: 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.
Hassan: It is not a language, but rather a language schema.
Chair: 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: OK. RuleML has two kinds of slots. Also, the FLORA system has only F-logic syntax. Some users have requested to have also the relational syntax. This is an example from user experience. FLORA has positional predicates, but people also wanted slots where positions don't matter. FLORA doesn't in fact support that, but its users want it; there is a real use case.
Gerd proposes that we should use use cases to identify the most important use of slots, and include that [semantics] in the Core.
Hassan Seconds Gerd's proposal to survey what sorts of slots we really need in actual rule languages.
Harold: Regarding the syntax and semantics of slots: We can have _extensible_ syntax for corresponding _extensible_ semantics. The various slot semantics may be characterized using a few new dimensions (in RIFRAF). One dimension is closed-slot vs. open-slot (subsumption) semantics for term/atom equality. This distinction can be expressed by starting with the closed-slot semantics part in that dimension, which is a purely syntactic variation of our existing positional semantics. Using a new syntactic construct, a kind of "rest" (or Prolog-list-like "|") marker, we can move to the open-slot part of that dimension; this syntax then entails F-logic's open-slot semantics.
Dave: Christian's statement on issue 12 is stronger than Gerd understands the RIF Charter to be committed to [scribe: is that with respect to all dialects counting as standard SW rule languages?].
csma: We don't know what the requirements are on a standard semantic web language, so wants not to commit ourselves to that.
Dave: But Christian's statement seems to say that the RIF WG will do no work towards making a standard SW rule language. If that's true, let's make it clear.
csma: There are things we will do, such as enabling RIF dialects to handle RDF and OWL. The point is not to commit to something more 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 see what that would be.
Chair: Agrees with Sandro that there is no consensus on what a SW rule language would be.
Dave: But you can read Christian's proposed wording as though *all* of the dialects would meet some minimum requirement for being a SW rule language. My concern is that people would make assumptions about what any dialect would do for them with the SW, 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?
Chair: Dave has a very definite idea of what a SW rule language should be and do.
csma: Would it be acceptable to say instead: "The design goal of each dialect is for rule interchange; some of them may also end up being useful as SW rule languages"?
Dave: Prefers the text that says the RIF WG is not doing work on SW rule language.
Chair: Doesn't want to preclude the RIF WG 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.
Chair: We will continue discussion on the above point in email and next week.
<Chair> 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 that part of the document is ready to send out. There is only one more item, related to Use Case 1, which needs to be addressed.
csma will look at what is needed for Use Case 1.
Chair reviewed the UCR action list. Actions to propose rule examples are deferred till the Core is finished.