<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.

Admin

<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

Liason

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 already.
... 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 property.
... 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.

Actions

Christian: I think actions 965 to 967 are obsolete
... we rolled back resolution and now need new actions

actions 965 to 967 have been obsoleted

close action-964

<trackbot> ACTION-964 Update public comment list closed

close action-961

<trackbot> ACTION-961 Check base64Binary case http://www.w3.org/2005/rules/wiki/Builtins_Binary closed

action 960 is continued

continue 959

close action-958

<trackbot> ACTION-958 Draft response to IH closed

continue 952

continue 951 (very close to done)

<Harold> Alex Riazanov action is ongoing

continue 940 and 941, he will draft replies shortly

continue 880

continue 850

Public Comments

Christian: We have 3 that need replies and there is a new public comment

<csma> http://lists.w3.org/Archives/Public/public-rif-comments/2010Jan/0000.html

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 proprietary syntax?
... 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

PRD

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?

Christian: Yes
... 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

Implementations

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 specified
... and also a logic programming dialect

XML Syntax of Import

<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].

SemTech

Sandro: Would anyone be available to be on a RIF panel at SemTech?

<csma> maybe

<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'

Test Cases

<MichaelKifer> I have to go, sorry

ChrisW: Love the Builtins_String test case

<ChrisW> http://www.w3.org/2005/rules/wiki/Builtins_String

<ChrisW> PROPOSED: approve Builtins String

+1

<ChrisW> +1

<Gary> +1 it works for me

<AdrianP> +1

<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)

<AdrianP> +1

<Gary> +1

+1

<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

<DaveReynolds> +1

<Gary> +1

+1

<AdrianP> +1

<ChrisW> RESOLVED: accept Builtins_boolean

AOB

ChrisW: Any other business?
... There will be a PRD telecon next week