See also: IRC log
<sandro> Harold, any response on the wiki problem yet?
<Harold> I am in another meeting; cannot join on the phone until in up to 60 mins.
<ChrisW> previous minutes: http://lists.w3.org/Archives/Public/public-rif-wg/2010Jan/att-0003/05-rif-minutes.html
<ChrisW> PROPOSED: Accept last meeting minutes
ChrisW: Any objections to above minutes?
<ChrisW> RESOLVED: Accept last meeting minutes
ChrisW: Any agenda ammendments?
Christian: Harold asked that we move the XML-syntax-for-import issue later
Sandro: And looks like Axel would like to talk about importing RIF from RDF
AxelP: I can only stay for 20 minutes
AxelP: I think we should define a
mechanism to import RIF documents from RDF
... this would be useful for SPARQL
... we want to query RDF+ RIF combinations from SPARQL
... and because of the way SPARQL is defined, querying a RIF document that imports RDF (which is what the WG has already defined) does not work well
ChrisW: You are suggesting defining RIF imports from RDF graphs?
AxelP: Yes, but we need to define the semantics of the import
ChrisW: Where do you think this would be documented?
AxelP: Ideally, RIF RDF & OWL compatibility doc, but it's late for that so maybe a WG note
DaveR: (Suggesting something with SPARQL entailment regimes)
AxelP: DaveR's suggestion is a minimilistic option, but not ideal because you can't refer directly to the RIF ruleset
<sandro> axel: Dave's approach would not allow the imported ruleset to be named in the graph
Sandro: I support what Axel is
suggesting. Another way to do this would be to have a way of
expressing RIF in RDF, and we are very close to that
... the SPARQL entailment regime idea would not provide support for non-SPARQL users who also want this capability
... I've been asked a number of times how to use RIF from RDF
ChrisW: How close are we to having an RDF syntax of RIF?
Sandro: I think we may just have to define a namepace; we are very close.
ChrisW: You mean we'd have to address the few places where RIF XML is not striped?
<sandro> sandro: yes, like var.
ChrisW: Any volunteers to work on this? I also get questions about how to import RIF from RDF.
Sandro: I can take an action for this
<ChrisW> ACTION: sandro to document an rdf syntax for rif [recorded in http://www.w3.org/2010/01/19-rif-minutes.html#action01]
<trackbot> Created ACTION-968 - Document an rdf syntax for rif [on Sandro Hawke - due 2010-01-26].
Christian: Why do you say that var is not striped?
<Harold> Var is a 'leaf class'.
Sandro: We didn't name the
... we only have literal content for var and const; const has an obvious mapping
<Harold> <Var>PCDATA</Var> uses XML's PCDATA, which can be mapped to an RDF property.
<sandro> So, in RDF, that would look like <Var><name>PCDATA</name></Var> (where "<name>" might be "<varname>" or .... something else. RIF doesnt say.(
<Harold> Rather than having another level of role tags within the Var class, I guess <Var name="CDATA"/> would be better for the purpose of RDF mapping.
Christian: I think actions 965 to 967
... we rolled back resolution and now need new actions
actions 965 to 967 have been obsoleted
<trackbot> ACTION-964 Update public comment list closed
<trackbot> ACTION-961 Check base64Binary case http://www.w3.org/2005/rules/wiki/Builtins_Binary closed
action 960 is continued
<trackbot> ACTION-958 Draft response to IH closed
continue 951 (very close to done)
<Harold> Alex Riazanov action is ongoing
continue 940 and 941, he will draft replies shortly
Christian: We have 3 that need replies and there is a new public comment
Stella: I think we decided (long ago) to provide RDF/XML versions of imported documents for test cases
Christian: I talked to this commenter about his issue and suggested he post to public list
ChrisW: I think that's up to implementations. There is only one normative RDF syntax right?
Sandro: Now there is RDFa
... I'm not sure that it's the case that RDF says there is only one normative syntax
ChrisW: I don't think RIF needs to take a stand on which RDF syntax(es) needs to be supported for imported documents
Christian: So an implementation can
claim to support RDF imports even if it supports only its
... another possibility would be to require a syntax indicator to go along with import statements so that consumers can check before processing
<ChrisW> ACTION: csma to draft response on public comment JA [recorded in http://www.w3.org/2010/01/19-rif-minutes.html#action02]
<trackbot> Created ACTION-969 - Draft response on public comment JA [on Christian de Sainte Marie - due 2010-01-26].
ChrisW: Do we have actions covering all unanswered public comments? ...Yes, looks like we do
Christian: I sent email summarizing the issue about refraction. I tested a few systems, but don't have a license for Jess
I think we have 3 issues:
...1. the modify in CLIPS is really a retract followed by an assert
... 2. in PRD we look at state only after each action block, but the update of the agenda in most systems looks after each change, and so includes intermediate states
... 3. currently the state of a rule instance is characterized by binding of rule variables, but this is not always adequate, specifially when there is a disjunction in the condition of the rule and the disjunction doesn't contain any rule variables
So my proposal is that we change the PRD spec
in three ways:
... 1. change definition of rule instance
... 2. consider refraction with respect to all the states of the fact base, i.e. after each atomic action rather than after each action block
... (above 2 are fairly minor)
... 3. change modify so that it is not an atomic action, and if we do this we don't need modify in PRD anymore so we can just remove it
<AdrianP> I would propose we keep modify with an atomic semantics
<AdrianP> Clips can represent their modify as retract+assert in RIF
ChrisW: Are these 3 points co-dependent?
... the Modify_noloop test case cannot be implemented in CLIPS
<Gary> I don't care about interoperating with clips.
<Gary> We need to consider some concrete test cases to better understand the issues here
Changhai: One possibility is to keep modify defined as it is now and remove Modify_noloop test case
<AdrianP> right, that is a problem of the Clips semantics which does not support atomic modifies
Christian: We can't keep modify as it is because that would mean we have something in the spec that cannot be implemented
Changhai: It can be implemented by some
ChrisW: We are discussing whether we need to change the semantics for CLIPS
Christian: Gary, how is modify implemented in Jess, in terms of agenda?
Gary: It's complicated.
ChrisW: Can Jess implement Modify_noloop?
Gary: No, but for a different reason than CLIPS cannot
ChrisW: Would the Jess problem with Modify_noloop require a PRD fix, and would that fix be different from the one Christian proposed?
Gary: I don't completely understand Christian's proposal yet.
ChrisW: Gary, what changes do you have in mind?
Gary: Not completely sure yet, but related to existential variables
Christian: No, taking bindings into account does not change anything with respect to CLIPS and JRules
Gary: For Jess it would
Christian: Details of behavior of different rule engines ... let's discuss more by email to clarify these situations
ChrisW: If the semantics needs to change we need to do another last call and we would want to do that as soon as possible
Gary: (Discussing slots and CLIPS, and not happy with the way CLIPS behaves in that respect)
<AdrianP> Jess modify changes the slot values of facts already in working memory
ChrisW: Christian, what granularity were you talking about with respect to facts?
Christian: Atom in the RIF sense
ChrisW: So, Christian will send some
examples to Gary.
... and does there need to be a PRD telecon before the next regular RIF telecon?
<ChrisW> ACTION: csma to send some examples of the failure case to gary [recorded in http://www.w3.org/2010/01/19-rif-minutes.html#action03]
<trackbot> Created ACTION-970 - Send some examples of the failure case to gary [on Christian de Sainte Marie - due 2010-01-26].
<AdrianP> yes, Tuesday would work for me
<ChrisW> ACTION: csma to schedule a PRD telecon next week [recorded in http://www.w3.org/2010/01/19-rif-minutes.html#action04]
<trackbot> Created ACTION-971 - Schedule a PRD telecon next week [on Christian de Sainte Marie - due 2010-01-26].
Gary: Christian, it would be helpful if you could come up with simple RIF test cases, positive and negative, relating to the issues you were talking about
Christian: Yes, I'll send them by the end of the week and we'll have a PRD telecon next week
ChrisW: Status of implementations, any news?
Christian: Jose Maria said they are
currently implementing DTB and asked whether they should
publish as a service or as a library
... this should be available within a couple weeks
... they are planning a complete implementation of DTB
... will be open source and in java.
... Also, Jos sent an email about implementations
ChrisW: Yes, Jos reported that STI is not going to
do anything soon
... is there any news on OntoBroker?
Christian: Unlikely that they would do more than they already have by the end of CR
ChrisW: No progress on fuxi implementation
Christian: We'll be doing additional work on JRules
ChrisW: How about Vampire/Eye?
Harold: Alexandre Riazanov is interested but not progressing as fast as planned
Gary: Oracle progressing, DTB is time-consuming
MichaelK: One FLD implementation has been reported to the RIF mail list
MikeDean: We have a SILK dialect
that is implemented but doesn't yet have a semantics
... and also a logic programming dialect
<ChrisW> ACTION: harold to update core, bld, and fld xml schema to reflect resolution on imports [recorded in http://www.w3.org/2010/01/19-rif-minutes.html#action05]
<trackbot> Created ACTION-972 - Update core, bld, and fld xml schema to reflect resolution on imports [on Harold Boley - due 2010-01-26].
Sandro: Would anyone be available to be on a RIF panel at SemTech?
<Gary> not me
Sandro: So far Sandro, Paul Vincent
<DaveReynolds> I'm a maybe
MikeDean: I'm planning to be there
ChrisW: I'm planning to be there, but not definite
Sandro: So we have Sandro, Paul Vincent, and Mike Dean definite for the SemTech RIF panel, and several more 'maybes'
<MichaelKifer> I have to go, sorry
ChrisW: Love the Builtins_String test case
<ChrisW> PROPOSED: approve Builtins String
<Gary> +1 it works for me
<ChrisW> RESOLVED: approve Builtins String
Gary: Builtins_Time....there is a typo relating to daytime vs. datetime, and two typos in the XML relating to commas or semicolons
XML: ," (twice), look for commas in the PS
<ChrisW> PROPOSED: accept Builtins_Time (modulo a few ximple typo fixes)
<DaveReynolds> 0 (just because I haven't checked!)
<ChrisW> RESOLVED: accept Builtins_Time (modulo a few ximple typo fixes)
ChrisW: Why is forall in the test case? (unnecessary)
Stella: Should we remove forall?
<ChrisW> PROPOSED: accept Builtins_boolean
<ChrisW> RESOLVED: accept Builtins_boolean
ChrisW: Any other business?
... There will be a PRD telecon next week