See also: IRC log
<csma> /invite zakim #rif
<csma> /invite rrsagent #rif
<csma> Meeting RIF Telecon 3 July 07
<csma> Mike_Dean, can you scribe today?
yes
<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?
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
nexttopic
<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
<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
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.