3 Jul 2007

See also: IRC log


Harold, josb, Mike_Dean, PaulaP, +1.703.999.aaaa, Dave_Reynolds, AxelPolleres, ChrisW, Sandro, +1.703.999.aabb, Mark_Proctor, LeoraMorgenstern, Christian, PaulVincent, +22427aacc, JeffP
Christian de Sainte-Marie
Mike Dean


<csma> /invite zakim #rif

<csma> /invite rrsagent #rif

<csma> Meeting RIF Telecon 3 July 07

<csma> Mike_Dean, can you scribe today?


<scribe> scribenick: mdean

<csma> Agenda http://lists.w3.org/Archives/Public/public-rif-wg/2007Jul/0000.html

<csma> sorry, difficulties joining...

<scribe> Scribe: Mike Dean

<csma> do you hear me?

<markproctor> I'm on the phone.

<JeffP> /zakim, who is here?

Christian: next meeting next week same time

<AxelPolleres> we seem to not have minutes from last time.

<AxelPolleres> right?

Action Items

no changes to agenda

<LeoraMorgenstern> Christian, is Gary Hallmark here today?

no minutes yet from last meeting

Leora: move Gary's discussion to next week?

Christian: start with discussing RDF part
... PR in core discussion also includes actions on Paul Vincent and csma
... start with RIF and RDF discussion


<Harold> Adrian Paschke asked me to mention: Please consider to submit an abstract to RuleML-2007 <http://2007.ruleml.org/cfp.htm>. Abstract Submission before July 10, 2007. (Paper Submissions due July 20, 2007.)


Harold: submission deadline for RuleML 2007 is now 10 July

<christian> am i here

PaulVincent: final PRR submission at September OMG meeting - finalization request


Chris: no news

Harold: will discuss financial aspects internally today - focusing on hospitality - technical issues are fine

<Harold> Preferred Possible date: Sept 17-18

discussion of dates and 8 week rule last week

<Harold> Another Possible date: Sept 6-7

Christian: currently preferred date is Sept 26-28

<josb> ack +39.047.101.aaaa

Harold: action with jos also depends on multi-sorted discussion from F2F6

action-299 now due July 13

action-300 now due July 13

action-301 now due July 13

action-309 now due July 6

action-310 now due July 6

action-307 dropped

scribe: not a commitment to anyone else

action-314 done

scribe: will be discussed later

action-318 done

scribe: may discuss later

action-319 should be completed by Friday

action-320 may be dropped later today

Jos's proposal for RDF in RIF

<josb> http://www.w3.org/2005/rules/wg/wiki/Arch/RDF

josb: 2 issues wrt RDF direction
... RDF Schema graphs as background knowledge
... exchanging N3-like rules (triples in the head)
... refer to external RDF graph using dataset mechanism, import as RIF facts using RDF(S) semantics
... extend vocabulary of datasets to support RDF

<josb> http://lists.w3.org/Archives/Public/public-rif-wg/2007May/0077.html

josb: embedding ISO proposed earlier (URI above)
... specification still volatile, depends on sort mechanism which will be removed
... embedding will become simpler
... exchanging N3-like rules
... depends on how you identify what kind of rules sent over wire - depends on vocabulary - issues with embedding
... blank nodes in the head
... also depends on sort mechanism - need to rethink when that's removed

Axel: N3 is a placeholder for simple rule languages?

josb: yes

Axel: N3 has some specific issues

Christian: N3 is partial demonstration, but doesn't really impact RIF except with blank nodes
... but RDF as background knowledge has impact on content and implementation of Core

josb: only impact if background knowledge is used

Christian: Core does require metadata import?

josb: proposal on how to implement, not requirements

Christian: related to proposal on datasets?

josb: yes - may require that everyone implement RDF datasets

<AxelPolleres> I assume that what jos writes here, equally goes for SPARQL CONSTRUCTS, Jena Rules, etc.

DaveReynolds: bNodes in head and builtins, e.g. isBNode
... requirements on Core

<Harold> DaveR, BNodes in the head correspond to existentials in the head, which goes beyond Horn.

Christian: what would be required for implementations that don't already implement RDF?
... does RIF Core require implementing RDF?

<AxelPolleres> We go into the same issue as last time, right? function symbols are another example...

DaveReynolds: Charter requires mapping from RIF Core to RDF
... requires solution

Christian: depends on how core is core discussion
... is there a way to express these specific builtins beyond RDF?

DaveReynolds: some concepts (e.g. language tags) are more generic

<PaulVincent> But isn't RDF another datatype like XSD/XML? So any dependancies on this should be abstracted out of Core-is-core?

<Harold> BNodes in the head goes beyond Horn, removing function symbols goes below Horn.

DaveReynolds for Jos: can we just import datatype entailment rules?

Jos: agree completely

Christian: semantics of RDF would be implemented by RIF rules?

<AxelPolleres> Not all RDF entailment rules can be written as RIF (CORE) rules, e.g. the 'map' entailment rule (ie. renaming bnodes preserves entailment), cannot really written down as a rule in the sense of RIF, right?

Christian: sufficient for implementations that don't support RDF?

josb: depends on entailment regime used
... identify rules in spec
... simple for translator to insert rules in ruleset

Christian: is it enough to just implement this way of using RDF
... does not impact definition of Core

^definition^current definition

axel: not all RDF rules can be written as Core rules
... e.g. renaming bNodes
... ESWC paper gave minimal set of entailment rules for several subsets of RDF(S)

<Harold> ESWC'07 paper: Sergio Muñoz, Jorge Pérez and Claudio Gutierrez (four U’s in Chile): Minimal Deductive Systems for RDF .

axel: OK for most use cases

<AxelPolleres> Graph: _:a p o.

<Harold> <http://www.eswc2007.org/pdf/eswc07-munoz.pdf>

ACTION (Axel): send example

<AxelPolleres> entails _:b p o.

<AxelPolleres> how could this be expressed?

<Harold> Introduces rho-df = {sp, sc, type, dom, range} semantics/complexity.

Christian: no reason Core must cover all of RDF
... just have to show it is compatible

<DaveReynolds> Axel: simple entailment handled by the query, you do want you rule system to generate an infinite number of renamings

<DaveReynolds> s/do/do not/ !!

Christian: don't have to exchange any RDF rule - may use dialect

<Harold> I propose to focus on the rho-df subset of RDFS.

<josb> _:a p o is embedded as Exists ?x[p-> o], and skolemized when doing reasoning

<DaveReynolds> Harold: I disagree

Christian: what can be abstracted from RDF data model

<AxelPolleres> Dave: completely agree, we also do not want the infinite axiomatic triples to be generated by an implementation,

<AxelPolleres> ... for being compatible.

<josb> if you want to check entailment of _:b p o, then query ?x[p-> o]

<AxelPolleres> I just wanted to make clear that we should clearly state that this 'usually' doesn't matter and have some discussion on whether/where this is indeed true.

Christian: what changes does this proposal require to Core document?

<Harold> DaveR, with "focus" I mean users who do domain modeling with RDFS should be encouraged to see if the rho-df subset is all they need.

<DaveReynolds> Harold: it is not

josb: changes to Architecture document, don't require changes to Core

<Harold> DaveR, Can you explain here, or off-line?

<AxelPolleres> Just to make clear again: I see no "problem" at all with jos' proposal, just, if we propose a set of rdf rules for emulating RDF(S) we should make clear what is covered and what not!

<josb> Everything is covered!

<Harold> The Core is Horn, so has no existentials in the head.

DaveReynolds: need to represent node types with builtins: Resource, typed literals, plain literals with language, bNode
... SPARQL builtins useful but may not be required
... Core document doesn't list specific builtins
... assuming rif:iri is close enough to Resource
... questions about literals and (rigid) head bNodes

josb: identifying bNodes is an issue for N3 rules
... not entirely sure

DaveReynolds: how about bNodes in facts?

josb: possibility

DaveReynolds: could have bNode as datatype

josb: possibility

Christian: what needs to be changed about IRI to accommodate Resources?
... don't want to focus on IRIs pending resolution on sorts

ACTION (DaveReynolds): summarize RDF requirements on current Core

josb: email discussion between Dave and Michael on modules
... both identified this as important issue

<PaulaP> +1 to supporting modules and discuss this issue further

<josb> http://lists.w3.org/Archives/Public/public-rif-wg/2007Jun/0066.html

Production Rules in Core

PaulVincent: main requirement is that Core expression language maps onto condition and action parts
... accommodate actions not just assertions
... set handling using rule variables - should be handled by generic sets in Core

Christian: related to pattern matching and unification
... but Hassan is not here today
... what makes a PR?

PaulVincent: pattern matching is side-effect of using RETE

Christian: deeper than pragmatic?
... every fact implicit

MarkProctor: modern RETE allow matching over a variety of sources - could be derived value or function call
... not just patterns over asserted entries in working memory
... stuff outside working memory can be unified with items in working memory

Christian: question more related to logic variables
... example related to lists

<csma> p(z) :- q(list(x,list(y,z)))

<csma> q((a b c d))

Christian: how to translate this into production rules

MarkProctor: unification somewhat simpler in PR
... have to simulate this

Christian: is this intrinsic to PRs

MarkProctor: RETE can do this, will include in next release, not aware of other implementations

<Harold> Mark, do you have a package of production rules to simulate unification?

<markproctor> not at at the moment

<markproctor> we are releasing 4.0 in 2 weeks

Christian: 2 main issues with PR and Core
... relation between atom in head and actions

<markproctor> after that building a full hybridge engine, with prolog style unification and proofing is our main task.

<markproctor> so we won't have anything for a few months.

Christian: translation of unifification to pattern matching

<Harold> But you'll have unification 'built into' your release 4.0 instead of just simulating it?

<markproctor> to get a PR system to simulate it now, its kinda messy.

<markproctor> not prolog style unification.

<markproctor> just Rete pattern matching and joins.

<csma> forall ?l:list, ?l2{?l.tail()}, z{?l2.tail()}, if Q(?l) then P(z)

<Harold> Well, an explicit 'unify' function would already be helpful.

<markproctor> best thing to do is provide me simple prolog examples

<markproctor> and I'll try and translate the unification process.

<markproctor> but it'll take me a while to do, i.e. can't do it off the top of my head.

<Harold> OK, let's look into this (even without explicit action item).

Christian: is there a general translation to Core?

PaulVincent: not acceptable to require complex transformations - should have closer mapping

Christian: is common core mapping possible? if not, change definition of core

<Harold> Christian, why did you rename your earlier variables x and y (but keep z)?

<markproctor> my prolog/proofing experience knowledge is kinda new, so I'm a bit behind you guys with that side of things ;)

Christian: PR to Core is not a problem, since unification is more powerful than pattern matching
... LP to PR is a problem

PaulVincent: secondary issue - research topic
... far more likely to want to handle PR in logic

Christian: compliance doesn't necessarily require symmetry

MarkProctor: PR can be extended to handle logic, but doesn't come out of the box
... look at modern PR systems

Christian: simple way to exchange rules that produce the same results?

MarkProctor: don't seem commercial demand for bi-directional interchange
... but definitely doable with some work

<Harold> Christian, Mark, how would you do both of these, even for facts only? Rulebase: knows(John John). Query: Exists ?x knows(?x ?x). As well as: Rulebase: Forall ?x knows(?x ?x). Query: knows(John John).

MarkProctor: some vendors have started with background and then moved to forward
... for performance
... but direct translation also typically has performance problems

discussing Harold's example

Harold: non-ground facts in PR may be a problem - all free variables are universal

<markproctor> Harold: I can take those away, and try and convert. will take me a while to work out.

<markproctor> what do you mean by "ground facts"

Christian: can discuss via email

<markproctor> typically PR systems don't understand the usage of ariety to create records of data

<markproctor> you have "ordered facts" but thats just a list, the order has no real meaning.

<markproctor> this is why Jess has to use naming conventions, to drive backward chaining, it doesn't support ariety.

<Harold> I mean facts such as knows(John John) not containing (universally interpreted) variables.

<markproctor> useless is a bit of a strong word :)

<markproctor> its more we have limited resources, we should probably focus on mainstream real world uses.

Christian: would like to hear someone argue in favor of interchange symmetry
... any takers on action?

<Harold> Prolog can also has non-ground facts such as knows(?x ?x) containing (universally interpreted) variables.

<markproctor> ah so Ground is a record, un-grounded has a variable for search/unification?

Sandro: some use cases (e.g. vocabulary mapping) implementable in LP

Christian: interested in other direction, sending PR to LP
... leave question pending

<AxelPolleres> have to think about it, honestly.

<Harold> Mark, the non-groundness is inside the rulebase (not just the queries).

<josb> +1

<PaulaP> +1

Christian: meeting adjourned

<JeffP> +1

<PaulaP> bye

<markproctor> Harold: I'll go read up on that.

<markproctor> if people want to send me some simple prolog rules, I can recreate in existing PR languages.

<markproctor> but the result is messy I think.

<markproctor> but it did seem the end result is no one is interested...

<markproctor> although might be worth while, just to help with understanding....

<csma> zakim who is on the phone?

<Harold> Yes, Mark, prolog rules in PR and PR rules in prolog should help with mutual understanding between both communities.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/07/03 18:05:24 $