<scribe> scribe: gary hallmark
<scribe> scribenick: GaryHallmark
csma: continue sorting based on degree of agreement
<sandro> ... and clarifying wording
csma: widescale adoption/low cost of implementation/low transfer cost
sandro: split it up
... emphasize real time performance
daveR: why real-time goal?
paulV: means low deployment time cost
... low computation cost for consumer
<sandro> "Low Cost of Implementation" ==> cheap serialization
<sandro> small footprint? simple?
paulV: low complexity
<sandro> Latency is a different issue
piero: expressive RIF will yield shorter msgs
<AlexKozlenkov> Could anyone post the link to the very latest list of reqs? Thank you
piero: but expressive RIF may be more expensive to implement
<DavidHirtle> we're on 220.127.116.11
<AlexKozlenkov> Thanks David
csma: need further discussion for this requirement
<bonatti> ...and if RIF is expressive enough, one can encode his/her rule base in a compact way
<DavidHirtle> Alex, as we discuss them we are modifying some, but these modifications aren't viewable online (yet) unfortunately
<AlexKozlenkov> I see
<EvanWallace> numbering doesn't seem to match
<DavidHirtle> 1.2.3, within section 1
<DavidHirtle> (I know it's confusing)
csma: how to measure this requirment?
paulV: 1-10 seconds
<sandro> maybe: sub-second latency on transfer of practical 100-rule ruleset --- something like that.
<EvanWallace> got it
csma: moving right along to new goal: consistency with W3C
... RIF should support RDF
csma: RIF should accept RDF triples as data
paula: means rules work with RDF data
paulV: is this obligatory or just feature?
<AlexKozlenkov> Does it mean that RDF can be only in the body of the rules?
csma: what is relationship with SPARQL?
<DaveReynolds> (b) implicitly talks about RDF in head, we are currently talking about (a) which, yes, is about the body
sandro: RDF more integrated than blackbox SPARQL
sandro: need RDF in reactive rules not just Horn
sandro: all RIF dialects should accept
... as data
<AlexKozlenkov> Gary, what about SQL data?
paulV: is RDF a requirement (mandatory?) of RIF or all rule languages using RIF?
<pfps> If the RIF can't handle Semantic Web data, then what is the RIF WG doing in the SW activity?
sandro: must all RIF dialects support integers?
... and so for RDF triples
csma: need more discussion
sandro: ambiguous: RDF Data Model vs RDF/XML Serialization
sandro: RDF brings along XML Schema datatypes
csma: rephrase to: RIF should support RDF data model?
daveR: if its in RIF core, its in all extensions, too
paulV: this is a strong constraint
chrisW: can't constrain all rule languages
sandro: need to define conformance
davidH: requirement is on RIF, not on rule languages
<sandro> sandro: If you want conformance to RIF, then you need to support ....
csma: again, needs more discussion
... next: RIF should support RDF deduction rules
... Hearing none.
Axel: what does "cover" mean?
Sandro: e.g. RDF deductions available as additional RDF data
<sandro> So this is a shortcut for RIF Must Cover N3 / Jena Rules
csma: SPARQL queries covered this morning, Dave has action
... next: Support OWL - are issues here the same as with RDF data?
kifer: is every OWL feature required?
josb: may depend on how it is integrated - e.g. like SWRL or more loosely
daveR: can't presuppose blackbox (loose) integration
<sandro> If blackbox approach to OWL integration, then this is the same as call-out. But not all support that.
josb: pfps may want to comment
sandro: need to resolve phasing to make more progress here, for ALL requirements
<sandro> pfps, you're not actually listening, are you?
kifer: what does it mean to include OWL subset relations in RIF?
csma: next: support XML
kifer: need more precise defn
paulV: often used by PR
sandro: map xml to prolog term
<sandro> mkifer: there's an approach where you use XML documents as templates
kifer: is this similar to xml extensions to SQL?
csma: can owl, rdf, and xml data be generalized to "data source"?
sandro: seems straightforward
... I think it's important to approve this requirement, as is
chrisW: RIF should handle interchange of XML data without
<sandro> DaveR: yes, but also for RDF
chrisW: ditto for RDF and OWL
<AlexKozlenkov> I'm wondering if direct access to SQL should be allowed. That would allow us to tap into the world of industrial databases
sandro: There are two kinds of compatibility with RDF -- at the low model level, I want that in ALL dialects; at the detailed level it can be only in some dialects
DaveR: You can do useful pattern matching on XML documents"
csma: set of requirements around data sources and external
calls (sparql, xslt, etc)
... should deal with them in a uniform way
<josb> scribenick: bonatti
csma: equivalent to supporting built-in XML elements?
<DavidHirtle> see: http://www.w3.org/TR/xmlschema-2/#built-in-datatypes
csma: (equivalent to David's point)
<DavidHirtle> (to avoid confusion)
<sandro> Charter: In Phase 1, the format must support literals and common functions and operators for at least: text strings (xsd:string), 32-bit signed integers (xsd:int), unlimited-size decimal numbers (xsd:decimal), Boolean values xsd:boolean), and list structures.
<sandro> -- http://www.w3.org/2005/rules/wg/charter
Dave: need clarification
hassan: what extend of XML schema is to be supported?
sandro: more than elementary datatypes; charter mentions lists
dave: mentions restrictions to datatypes
csma: this needs to be clarified
<sandro> Clarify relationship to XS unions and restrictions on types
<DaveR:> RIF must be clear about which XS features are required for Conformance
csma: next: RIF should cover LP + negation as failure and
csma:"strong negation" needs clarification
<sandro> "Strong Negation" is more related to 3-values, or maybe intuitionistic/constructive. No Excluded Middle.
MichaelK: strong negation is like
classical negation but not quite
<sandro> summary: Strong Negation is like Classical Negation but without Law Of Excluded Model -- part of stable model semantics.
Piero: There is no interplay between positive and strongly-negated atoms. Strongly-negated atoms are like atoms re-written.
bonatti: strong negation can be "implemented" by replacing
strongly negated atoms with new atoms uniformly
... puts no requirements on negation as failure (such as stratification)
<josb> strong negation is part of the answer set semantics, which in turn is based on the stable model semantics; strong negation is an extension of the stable model semantics
<sandro> DLV supports both
<sandro> => "strong negation" as in DLV
csma: let's use DLV as reference to specify what we mean
harlod: Wagner (REWERSE) has proposed/supported strong negation
sandro: isn't this good for phase 2?
<sandro> Handle this under Phase-2-RIFRAF.
csma: maybe such things should be discussed as a whole
<josb> THE reference on strong negation in logic programs, implemented in, e.g. DLV: http://citeseer.ist.psu.edu/gelfond91classical.html
harold: modules similar to contexts etc
scribe: efficiency is important
csma: can we propose concrete languages needing this?
... isn't this a property of a language, rather than RIF?
Josb: many languages (eg flora) have modules and have to be exchanged
harold: modules should be a requirement
<AlexKozlenkov> I have a question, should each individual rule have unique id? Also, if module id can be dynamically assigned, one could add/remove rulesets in one step.
sandro: working memory, a DBMS are example of scopes
<AlexKozlenkov> What I am saying is that rules may be accessed both individually and as groups
csma: needs discussion, strongly related, actually belongs to, RIFRAF
<sandro> PROPOSED: add a requirement that all features in RIFRAF are requirements
davidh: add a requirement saying that all prioritized
features described in RIFRAF are to be covered by RIF
<sandro> DaveR: We'll use RIFRAF to identify the features we cover
PROPOSED: RIFRAF will identify the set of languages to be covered by RIF
daveR: We'll use RIFRAF to identify the set of language features RIF may cover
PROPOSED: Every feature in RIFRAF will be discussed in the future as a possible Requirement.
harold: No -- they are orthogonal
<GaryHallmark> RIFRAF must be "larger" than the set of requirements (currently it is not, e.g. reactive rules)
PROPOSED: We will use RIFRAF to identify classes of language to be covered by RIF
PROPOSED: We will use RIFRAF to identify classes of languages to be covered by RIF
RESOLVED: We will use RIFRAF to identify classes of languages to be covered by RIF
<AlexKozlenkov> RIFRAF surely has more bearing on derivation rules
<AlexKozlenkov> Does not mean that RIFRAF will be extended to cover, say, reaction rules?
<sandro> AlexKozlenkov, what you're seeing is that RIFRAF right now only covers phase one -- Horn rules.
<DaveReynolds> Alex, yes I would say it should
<AlexKozlenkov> Can we explicitely mention that it will be extended, so that it is written down
<sandro> It should be in the minutes of the RIFRAF session earlier today, I think, Alex.
<AlexKozlenkov> OK, thanks, Sandro
harold: for each dimension there can be
multiple choices -
e.g. e.g. to
support vs. not to support
... user/equality-defined functions (LIFE vs. Prolog)". This is an example where pointing to a RIFRAF
... dimension is not enough to express a design constraint: You have to say which value you pick
... in that dimension. For details see Hassan's email on logic with equality.
... not every combination of features in RIFRAF shall be supported
numbers in the discussion below refer to the items in the "Full
statement" section of
chrisW: 1-3 look like requirements
gary: 1 and 2 similar to the data sources issue
csma: nobody really understands "UML Instances": it should be postponed
<sandro> Category -- data access by rules
chrisW: should we describe these languages as classes of RIFRAF features?
<sandro> "Data Sources"
<EvanWallace> Sound dropping out a lot
<AlexKozlenkov> I guess the mic is not being passed around really
<sandro> RIght. It's incredibly hard/expensive to pass the mic around, so we sometimes give up on it.
dave: let's move the SBVR point to RIFRAF and discuss "UML instances" and "ORM fact model populations"
gary: some languages can import business obj model from UML
csma: this has to do with sharing obj models - this is orthogonal
<AlexKozlenkov> Eclipse Ecore/EMF is one way to store UML instances, one can run OCL queries on it, one could also imagine a RIF integration
paulv: representing OCL as rules is an interesting topic, too
<AlexKozlenkov> OCL querying on EMF instances is actually quite cute
<AlexKozlenkov> Integrating EMF instances with RIF has value
somebody: refers to rule validity (in time)
csma: it has to do with rule management, not interchange
<AlexKozlenkov> I see
paulv: it is redundant - it could be done in rule languages that support time
hassan: no, it has rather to do with versioning
chrisW: the wiki page mentions "retrospective analysis"
paulv: such a "what-if" kind of reasoning is beyond the scope of RIF
dave: time validity could be part of the metadata (rule-tagging) effort
csma: discuss later with metadata
<sandro> Charter: RIF "must include a way to express facts as well as rules, and also metadata (annotations) about documents, facts, and rules. "
csma: having time validity means that a compliant application should ignore them if outside validity period
<AlexKozlenkov> There is a whole range of issues related to rules management. E.g., is RIF concerned with the rights management?
chrisW: not like "author" meta-tags: validity tags affect execution/reasoning
dave/csma: there is a requirement that RIF covers metadata: should we discuss it or just provide a mechanism to add metadata?
<AlexKozlenkov> One could say: limit inference to specific rules source/origin
<AlexKozlenkov> Extensible metadata should be a requirement. We cannot predict all the types of metadata people would want to associate with rules
gary: the question is about metadata in general
somebody: i.e. something like comment tags
chrisW: if this just means "comments" then we all agree
<AlexKozlenkov> Aren't comments part of metadata?
somebody: needs further discussion
davidh: only some of the issues here are requirements
csma: it duplicates previous discussion on data sources
gary: during last f2f facts were distinct from data
harold: data are not given any model-theoretic meaning
csma: it's in the data source discussion
csma: goes to RIFRAF
paula: Allen made a proposal not in the list of issues on
design constraints: should it be discussed?
... it can be found in the e-mail archive
csma: it won't be in the draft to be produced on friday, so its discussion is postponed
csma: meet you all tomorrow at 8...
<sandro> Telephone: goodnight!