scribe Axel
scribenick AxelPolleres
ChrisW: Go through list discuss level of agreement, no classification yet.
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
<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
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"
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
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.
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
(slide 12)
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.
(slide 13)
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
ChrisW:needs further discussion.
ChrisW:needs further discussion.
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]
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"?
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
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
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"
(slide 19/20)
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
(slide 21)
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
(slide 22)
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!