scribe Axel

scribenick AxelPolleres

Requirements

ChrisW: Go through list discuss level of agreement, no classification yet.

1.1.1.a Formal semantics

Igor: What about languages which don't have a formal semantics?

Paul: Examples?

csma: Better: what does formal mean here?

Piero: precise and mathematical specified.

Gary: SQL for instance has only structured Englisch def. Should be good enough. Adjust the requirement.

csma: When you get a ruleset through the RIF, you should be able to get the same results everywhere.
...Should define what it means to use the same ruleset. "formal semantics" maybe too strong
... are there objections against the requirement or the phrasing?

<sandro> ChrisW: When you get a ruleset in RIF, the meaning of the Ruleset will have a clear and precise semantics.

<scribe> ACTION: Paula capture proposals for rewordings for "1.1.1.a Formal Semantics"

csma: rewording proposals,e.g. "clear and precise"

<Harold> If we feel that "formal" is too much to ask of certain (sub)languages of RIF (Igor: Production Rules), the term "rigorous" may be better, because it does stronger than "clear" and weaker than "formal".

<bonatti> "formal" can be applied to certain fragments; for "operational"fragments one might resort to weaker definitions

1.1.1.b Interchange of rule sets will often involve different semantics ...

<sandro> Sandro: is this all-models vs minimal-model semantics?

csma: understanding: RIF should cover exchange even if semantics is not shared.
... e.g. stable model semantics vs XYZ

MichealK: better "different styles of semantics"

<sandro> csma: Multple Semantics: RIF should be able to cover rule languages with different styles of semantics

<sandro> (proposal)

Hassan: proof theoretic vs. model theoretic is not a discriminator, because one can coincide with the other.
... equally called operational vs. declarative

Gary: for ECA production rules the best you could do would be a kind of abstract machine semantics.
...I don't want something to preclude various styles of specifying semantics

<Harold> Multiple semantics: Styles of semantics (e.g. proof-theoretic vs. model-theoretic) should be distinguished from variations of semantics (LP vs. FOL).

csma: two things: "different ways to define semantics" and "different intended semantics"

JosB: the first is not a difference, the second can be mutually incompatible, thus we need this requirement

<Harold> However, the variations of semantics should be done in a disciplined manner, with a well-defined characterization of the differences.

Proposed text for the requirement (from slide):RIF should be able to cover rule languages with different intended semantics for the rules

<sandro> general agreement on 1.1.1b

DECISION:proposed text accepted

1.1.1.c Markup of semantics

csma: This is equivalent with the previous one.

ChrisW: this is a consequence from the previous two.

sandro: If you don't implement the semantics tag, you throw it away.
...it == the ruleset

csma: there can be overlaps if you just discard a rule set for a different semantic "tag" e.g. full horn vs. datalog

<josb> +1 to csma: tag is solution; not requirement

harold: the intended semantics should be reflected in the syntax
...refer to charter, mentions annotations already.

<sandro> "The intended semantics of the rule set in a RIF document should be charactized syntactically"

<sandro> "identified" instead of "characterized"

csma: 111a is clear and precise semantics, 111b is more than one, 111c is they should be "identifiable"

<sandro> "RIF should have a standard way to specify the intended semantics of the rule set in a RIF document"

<Harold> Let's distinguish the semantics of the layers of the RIF language and the semantics of a given RIF document, which should refer to the intended layer.

<sandro> "RIF should have a standard way to identify the intended semantics of the rule set in a RIF document"

<sandro> "RIF should have a standard way to specify the semantic style of the rule set in a RIF document"

Proposed text (from slide): RIF should have a standard way to specify the intended semantics / semantic style of the rule set in a RIF document

paul: commercial languages tend to "grow", how to deal with that?

<scribe> ACTION: Paul to describe an additional requirement for evolving semantics and check whether this is already covered in "extensibility"

1.1.1.d Meta language features

sandro: drop this requirement.

<DavidHirtle> this doesn't fit under "Soundness"

<DavidHirtle> (probably "Coverage")

csma: seems to be subsumed by extensibility

<josb> note: meta-languages fit in extensibility, as well as coverage, according to the diagram

Requires further discussion

1.1.2 Coverage

1.1.2a The RIF should support deduction rules

Sandro: synonym for "Logical Rules"

Paula: better general "logical rules"

piero: deduction rules vs. integrity constraints
...this is about how the rules are used -- for users
...i.e. deduction rules means rules that produce more information

Sandro:  this provides organization/classification for rule languages for us to cover

<sandro> "rewrite rules" ?

Discussion: Does the requirement name specific languages or classes of rules (deductive (FOL and LP style), normative,reactive)?
... to be discussed

<Harold> The LP vs. FOL distinction could me made orthogonally to the deduction vs. normative vs. reactive distinction:

<Harold> E.g. there are LP normative rules.

1.1.2.e Combined rulesets

paula: previeous topic missed the requirement on "coverage of prolog style rules"

chrisW: this is in the same bucket as the previous (1.1.2.a->1.1.2d), back to combined rulesets

csma: the requirement should be about combining rulesets not about combining classes of rules.

<PaulaP> +1 to Christian

michaelK: RIF must cover rule languages which support multiple styles of rules (eg normative and deduction)
...e.g. deductive and normative appear already in the same rulesets, e.g. in LP

chrisw: further discuss this one with the prevous one.
... (the aspect of combined rulesets which combine different types/classes of rules)

DavidHirtle: call this an objective

1.1.2.e.b part one: "The RIF should support rule sets where rules are composed of features from multiple rule languages."

<josb> +1 to ChrisW: we cannot allow arbitrary combination of features

MichealK: combination of semantics difficult to define.

<DavidHirtle> ("objective" is what e.g. OWL UC&R document calls "nice to have" features)

<DavidHirtle> (see http://www.w3.org/TR/webont-req/#section-objectives)

<sandro> Axel: this sounds like an open research question

ChrisW: next issue, this requires further discussion.

1.1.2.e.b part two: "a condition in a RIF rule may be a SPARQL query."

Chris W: should be "for example SPARQL"

AxelPoller: 1.1.2.e.b part one is not feasible, part b should be rephrased.

[Internet connection lost]
ACTION: Dave to rephrase 1.1.2.e.b

1.1.2.f RIF should support uncertain and probabilistic information

ChrisW:needs further discussion.

1.1.2.g All requirements that are under the CSF 'Alignment with Semantic Web'

ChrisW:needs further discussion.

1.1.3. Extensibility

1.1.3.a Support typed languages

PaulV: datatypes like XMLSchema types, etc

Gary: typechecking for functions and predicates

JosB: Datatypes or also ObjectTypes, with OWL compatibility we have part of this already.

ChrisW: this is NOT an anchor into OWL.

[Internet connection back]

1.1.3.b Support oracular models

ChrisW: this is unclear.

Harold: better callout to "blackboxes". Oracle is bad wording.

ChrisW: One could argue that this is a violation of the "no surprises" requirement.

Axel: doesn't this link to semantic annotations of services.

<scribe> ACTION: csma to explain why this "blackboxes" is not a contrdiction to "no surprises"

<sandro> (more than "External Queries")

csma: merge with "external calls"?

1.1.3.c Markup of semantics

Scribe: AHarth

sandro: if you extend the language that might break some things

bonatti: we might have a translation from one dialect to another which is not complete, i.e. doesn't cover all features

csma: if you retrieve a ruleset that you cannot process completely it should not break your application?

chrisW: anyone who thinks they understand that requirement?

<AxelPolleres> isn't this like "must understand" in SOAP, e.g.?

<sandro> it's closely related, Axel.

harold: title is a repetition of the earlier title, should be able to interchange the semantics

paul: is this talking about partial coverage of the semantics? part of the graceful degredation aspect?

<sandro> Yes -- it will result in the same designs

dave/chris: move this to the next requirement which covers conformance?

chris: rif must be extensible is a requirement?

sandro: that's more a success factor

csma: the charter says we must specify "how out of scope features can be expressed by extensions"
... inability to extend should be addressed by text that explains
... are there two different types of extensibility which need to be made explicit?

chris: is the issue whether it's a req or a critical success factor?
... let's move on

1.1.3.d Conformance model

jos: what is a conformance model? if you have a specified semantics, you know what the language means

csma: first is the granularity level, the other is related to the processing model
... how do you know that the other side is able to process your rule

sandro: how do you do conformance in the face of extensions?

<sandro> (that's what this addresses)

sandro: is another way of saying it

Proposed text (from slide): RIF must specify at the appropriate level of detail the default behaviour that is expected from a RIF compliant application that does not have the capability to process all or part of the rules described in a RIF document, or it must provide a way to specify such default behaviour. That default behaviour must be easy to implement independently of the rule-processing capability of the consumer application.

chris: any objections to this as requirement?
... general agreement, no objections

Decision: accepted

1.2 Widescale adoption

1.2.3 Low cost of implementation

csma: we're done with goal 1
... next one is low cost of implementation

davidhirtle: in the diagram there is no requirement supporting the low cost of implementation point

sandro: there are, e.g. using XML (for parsing)

csma: fact that it opposes other requirements means we have to find a trade-off

sandro: rif should be implementable using well-understood techniques

Dicussion topic: "It should be possible to build reasoners for intended ruleset languages without unnecessary burden"

csma: rif should not contain features that are not covered by existing languages, implementing reasoners is out of scope for rif

<PaulaP> +1 to csma

gary: what this means to me is that  it should be possible get an easy mark of compliance, without supporting lots of stuff.

chris: does that mean there are degrees of compliance?

csma: then, what do you do with the part you don't support?

chris: the current wording is overly vague

dave: one is under extensibility, while the other point is what's in a "rif core"?

chris: rewording: "there are conformance levels, and not all compliant aplications are supposed to support all of rif"

sandro: objection to trivial compliance

chris: there needs to be some minimal compliance

csma: postpone the "unnecessary burden" requirement

next one: well-understood implmentation techniques

csma: do we need to be more precise when we talk about rif implementation? reasoners vs. translators

chris: rif should be implementable - no objections

jos: implementable is not low cost of implementation

<sandro> approved: RIF should be implementable using well understood techniques"

chris: next - use of standard support technologies such as XML parsers
... XML is not necessarily low cost

csma: XML syntax is a requirement from the charter

chris: XML syntax should be under W3C compatibility

csma: support XML as data is different to XML as syntax for rif

<sandro> Gary: reuse existing reasoners

gary: reuse e.g. XSLT to translate from RIF to other formats

chris: Requires fursther discussion.
...lunch!

lunch