Admin

<ChrisW> last weeks minutes: http://lists.w3.org/Archives/Public/public-rif-wg/2009Feb/att-0042/03-rif-minutes.html

<ChrisW> PROPOSED: approve minutes of Feb 3 telecon

<ChrisW> RESOLVED: approve minutes of Feb 3 telecon

ChrisW: Any agenda ammendments? ... none

Liaison

ChrisW: Yesterday there was a joint OWL-RIF telecon. Several things were discussed. One item of interest is that OWL is considering not going with overlapping value spaces

<AxelPolleres> I was there (OWL-RIF teleconf)

<ChrisW> http://www.w3.org/2005/rules/wiki/RIF-OWL-datatypes

ChrisW: I started the above wiki page - the goal is to list the union of all the datatypes from the 2 (RIF & OWL) working groups

<AxelPolleres> While owl:rational sounds rational, I am worried about owl:real to be honest, sounds like a can of worms.

<LeoraMorgenstern> Just fyi, I will be half-on, half-off during this phone call due to conflicting obligations

ChrisW: The ideal scenario would be to have RIF and OWL agree on the same set of datatypes. If we can't achieve that, we would at least like to have the OWL-RL datatypes be a subset of RIF datatypes
... I'll be updating the wiki page with more information

AxelP: owl:rational - implementations will need libraries. I'm worried that owl:real is a problem for implementations, because not all values have a lexical representation

<sandro> (sorry I'm late)

<cke> (sorry I'm late too)

ChrisW: Also there is owl:realPlus. I hadn't been aware of that datatype before.

<AxelPolleres> xsd:dateTimeStamp totally make sense.

Sandro: I propose go for the intersection of the OWL datatypes and xsd datatypes

<AxelPolleres> +1 to sandro.

ChrisW: That's a reasonable approach if the 2 groups cannot agree on a common set of datatypes - but I'd like to try the common RIF/OWL set first

DaveR: I don't think real and realPlus are a problem

<sandro> DaveReynolds: owl:real and owl:realPlus are just named union types, so it's not really a problem.

<AxelPolleres> a(x) :- 2 = x * x.

DaveR: For RIF, it would just mean that with e.g. testing isLiteralOfType owl:real, one could test whether a symbol is any kind of number

<sandro> DaveReynolds: We don't need to implement "real" math to support the real types. Just our normal operations.

<sandro> DaveReynolds: We could say "we don't introduce ways of computing with reals, beyond what's in our other numeric types"

DaveR: I think owl:rational is more of a problem, because it's new, and most rule languages don't have support for rational numbers

<sandro> DaveReynolds: owl:rational sounds like a big implementation barrier.

<ChrisW> http://www.w3.org/2005/rules/wiki/RIF-OWL-datatypes

<sandro> ChrisW: will add three more columns to the table (wiki page above): support by owl, supported by rif, status.

<AxelPolleres> hearing this, owl:rational sounds more like "cool-thing-to-have" than "mature-to-standardize"

Sandro: xml schema group is thinking of adding rational numbers in the next version, so maybe it would make sense to wait for that

<DaveReynolds> Axel: if x is say xsd:double then x*x is an xsd:double by current DTB not a real.

F2F13

ChrisW: We haven't gotten any new proposals, so we'll have a poll on the existing options

Sandro: When do we need to decide by?

<csma> let me check

<csma> Yes, by next Tuesday

<csma> For the case it would be starting on April 15th

<ChrisW> F2F13 space-times: Madrid April 15-17

<ChrisW> Cambridge, MA April 15-17

Sandro: For the people who are here, who would not go to Madrid and who would not to to Boston?

<josb> I would go to either

<sandro> I would not go to Madrid

<AxelPolleres> madrid preferred, cambridge possible with financial pain

<cke> I would probably go either, but prefer Madrid

ChrisW: I would go to either

<DaveReynolds> I couldn't do either so depend on teleconf facilities, sounds like Boston would be better from that POV

<Harold> I would go to either

Sandro: I'll set up the poll

<AxelPolleres> http://lists.w3.org/Archives/Public/public-rif-wg/2009Feb/0001.html

Action Review

Christian: Action 704 - continued
... action 703 - Axel will send an email summarizing his findings so far
... action 701 - continued

JosB: I thought the action on Axel was to say what kind of restriction he had in mind? (703)

AxelP: Yes, it was both to contact implementers and to write strong safety restriction

... action 702 - pending review
... action 694 - pending review.
... action 692 - continued, Changhai has done some investigation on this, and still needs to do more. probably can finish in 3-4 weeks

Harold: I will do the schema for core, specializing from BLD, and then hand it over to Changhai

... action 691 - continued
... action 689 - pending review
... action 592 - continued
... action 588 - continued
... action 439 - continued
... action 152 - continued

Christian: action 681 is Pending Review, we'll close it because we'll discuss it in today's telecon:
... all other Pending Review actions will remain Pending Review

Issue-63 (ruleset construct in PRD)

<csma> http://www.w3.org/2005/rules/wg/track/issues/63

Christian: This issue is about whether PRD should have a specifc ruleset construct

<csma> PROPOSED: Close ISSUE-63 with the understanding that the Group construct is sufficient.

Christian: PRD task force discussed it last week, and we agreed to propose the above

Christian: Any discussion...any objection or abstention? ...none

<josb> +1

<Harold> +1

<csma> RESOLVED: Close ISSUE-63 with the understanding that the Group construct is sufficient.

Issue-65 (halting test in PRD)

<csma> http://www.w3.org/2005/rules/wg/track/issues/65

Christian: This issue is about the halting test in PRD. There is only one halting test defined in the current PRD spec

Christian: The PRD taskforce discussed this at the last telecon

<csma> PROPOSED: Close ISSUE-65 with the understanding that PRD does not add specific syntax to specify halting tests.

JosB: Do production rule languages represented by people in this WG have halting tests?

Christian: Mentioned one (?)

<cke> not in ILOG JRules right now, but we are adding it.

<cke> In JRules, the control is more done at the ruleflow level

JosB: Is it a condition formula?

GaryH: Halt is an action, and so you can write your own halting test

JosB: Why don't you add a halt action then?

<cke> Jos, "halt" is interesting to add, but not for a first version of PRD. Let's reserve it for later

<cke> The solution is to write a test in conditons that integrate the halting condition

<csma> PROPOSED: Close ISSUE-65 with the understanding that PRD does not add specific syntax to specify halting tests.

Christian: Any objections? ... abstentions? ...none

<josb> +1

<Harold> +1

<AxelPolleres> +1

<csma> RESOLVED: Close ISSUE-65 with the understanding that PRD does not add specific syntax to specify halting tests.

<sandro> +0

DTB

Issue-81 (support for additional OWL-RL datatypes)

<csma> http://www.w3.org/2005/rules/wg/track/issues/81

GaryH: We already have several date, time and timestamp types, which I think are sufficient. All of them have an optional timezone
... I think we missed a number of builtins that allow the creation of a date or a time from a string or an integer, and also operations to deconstruct dates/times and extract parts of them. I think this could be a problem

JosB: responding to GaryH re: builtins - the current builtins allow the operations you mentioned. Casting functions, section 3.2, section 3.5.1. I'm not clear on what is missing?

GaryH: Ok, I will look

<Zakim> sandro, you wanted to explain dateTimeStamp

Sandro: DateTimeStamp is different from the other date and time related types: it's a particular point in time, more precise

<LeoraMorgenstern> sorry -- I need to get off this call.

<josb> +1 to include datetimestamp

<cke> +1 to keep xsd types, and amont them xsd:dateTime.

Christian: Sandro, you are suggesting to add dateTimeStamp, right?

Sandro: Yes

<josb> correct

ChrisW: owl only has dateTime and not dateTimeStamp?

Sandro: Yes

<cke> owl:dateTime is at risk: it will be replaced by the future xsd type (i.e. xsd:dateTimeStamp?) when it will be available

Changhai: I wanted to keep xsd:dateTime because it's useful in some business rules and I have provided use cases for that

Christian: My understanding of Changhai's use case is that he wants to leave it to the consumer of the rule whether and how they use timezone in the rule
... and I think DaveR said that violates the semantics, but Dave isn't here to comment on that now

Changhai: When you write a rule (e.g. booking in restaurant for specific date and time), you don't want to specify timezone when writing the rule because you want the rule to be valid in all timezones
... when the rule is deployed, then the container should decide whether and what timezone to apply
... but for use as an interchange format we just need to ensure that the original information is preserved in the translation

<csma> PROPOSED: keep xs:dateTime, and add xs:dateTimeStamp

<josb> table, please

<cke> I agree

<josb> I want to hear what Dave has to say

<cke> I agree with the proposal

Christian: We will put this proposed resolution on the agenda for next week

<josb> owl:rational

<ChrisW> i'm back

<AxelPolleres> I guess we have no way to convince XSD to include text, right?

JosB: We promised the OWL people that we would check in RIF WG how people feel about owl:rational

ChrisW: What is the lexical represenation?

JosB: I will check

<josb> numerator '/' denominator

<josb> so, things like 1/2, 3/4, etc...

Sandro: DaveR argued that we shouldn't add owl:rational because most rules languages don't have support for rational numbers. I don't agree with that argument because I don't think all systems will implement all the RIF builtins anyway

ChrisW: And XML schema considers a rational datatype useful, and may add it in the future

AxelP: I don't see why we should add it if it's not supported by systems....can we find examples of systems that have it?

<Harold> Did some look at the numeric datatypes in Common Lisp?

<csma> +1 to Axel

<josb> The java library: http://www.lrdev.com/lr/java/BigRational.html

ChrisW: What do the product-oriented representatives think about adding this datatype?

<Harold> http://en.wikibooks.org/wiki/Programming:Common_Lisp/Numbers

<AxelPolleres> as I said, sounds "nice-to-have" I do not oppose owl:rational per se, just wanted to raise the question

ChrisW: Would anyone oppose it?

AxelP: Can we ask OWL WG which systems they have in mind?

Sandro: I think they are viewing it as a new and useful feature, they are not thinking of existing systems

<AxelPolleres> it seems to be a weak motivation for a *standardization* group, honestly, that is worrying me

<AxelPolleres> ... unless systems support it.

ChrisW: It is supported by OWL-RL?

<josb> yes

Sandro: Yes

Sandro: I mostly agree with Axel's standardization argument, I don't lean heavily either way
... I don't think the goal of aligning the datatypes is worth the implementation hassle

ChrisW: People should think about this, and we'll put it on the agenda for next week
... I don't think the implementation burden is too much

Issue-80 (meta builtins in DTB)

<sandro> issue-80?

<trackbot> ISSUE-80 -- Shoudl we extend DTB to include more general builtins -- OPEN

<trackbot> http://www.w3.org/2005/rules/wg/track/issues/80

<josb> We need to wait for Axel's action

ChrisW: Last week we had a discussion about the equality part of this issue

<AxelPolleres> http://www.w3.org/2005/rules/wiki/DTB#Guard_Predicates_for_Datatypes

AxelP: IsLiteralOfType isLiteralNotOfType some examples in DTB
... guard predicates will be affected the decision on the disjointness of datatypes

JosB: We already decided on isLiteralOfType and isLiteralNotOfType

ChrisW: People should check out the new guard predicates

JosB: I proposed to change BLD semantics, but didn't see any response to it
... proposal was that datatype IRIs are always mapped to the datatype

<sandro> jos: otherwise you could have very strange things, like making all literals be of type integer, etc.

<ChrisW> ACTION: chris to open an issue on whether datatype iris shoudl map to the datatypes themselves [recorded in http://www.w3.org/2009/02/10-rif-minutes.html#action01]

<trackbot> Created ACTION-705 - Open an issue on whether datatype iris shoudl map to the datatypes themselves [on Christopher Welty - due 2009-02-17].

AxelP: You said this would simplify the definition as well?

JosB: Yes, because for the second argument you can just talk about value spaces
... Can we close the action on Axel that is pending review because we now have this new issue?

<AxelPolleres> http://www.w3.org/2005/rules/wg/track/actions/681

<AxelPolleres> (that is the closed action we discussed)

Issue-90 (can rif:iri and rdf:text be used as datatypes in RDF graphs, in combination with RIF)

<sandro> issue-90?

<trackbot> ISSUE-90 -- Can rif:iri and rdf:text be used as datatypes in RDF graphs, in combination with RIF? ie approve http://www.w3.org/2005/rules/wiki/RDF_Combination_Constant_Equivalence_1, http://www.w3.org/2005/rules/wiki/RDF_Combination_Constant_Equivalence_Graph_Enta -- OPEN

<trackbot> http://www.w3.org/2005/rules/wg/track/issues/90

JosB: This was raised at the F2F and Sandro and DaveR were concerned. There is a discrepency between the types of symbols you can write in RDF vs. RIF

<josb> two ways to write "bla" in English in RDF:

<josb> "bla"@en and "bla@en"^^rdf:text

<josb> the question is whether to disallow the second one

ChrisW: There are some related test cases

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

ChrisW: Disallow importing RIF documents that use certain datatypes?

Sandro: I find this test case weird....because it allows writing IRIs in a different way that RDF is not used to

Sandro: Could be confusing. We could say that these two forms are equivalent in RIF systems, but they aren't equivalent in non-RIF systems
... in RDF it's a datatype literal with an unknown datatype

<AxelPolleres> we should discourage both rif:iri and rdf:text in RDF.

<AxelPolleres> Discouraging the use of rdf:text was also what Andy Seaborne suggested, wasn't it?

Sandro: The test referenced above in the irc is valid semantically, but should it be valid syntactically?

<josb> I'm fine with either

Sandro: And we have the same problem with rdf:text

ChrisW: What's the related test case, for the rdf:text issue?

JosB: There isn't one

<sandro> INSTEAD OF: <http://a> <http://p> "with language tag"@en .

<AxelPolleres> We could solve this by disallowing rdf:text and rif:text as a datatype in the pres syntax, couldn't we?

<sandro> TRY: <http://a> <http://p> "with language tag@en"^^rdf:text

<josb> PROPOSED: RIF-RDF combinations are not defined in case rif:iri or rdf:text are used in the imported RDF graphs

ChrisW: The point is that these literals only have meaning in RIF. We're not changing the RDF spec

Sandro: That's not clear with respect to rdf:text

AxelP: Can we disallow the use of rif:iri and rdf:text in the presentation syntax?

JosB, ChrisW: This isn't a presentation syntax issue.

<josb> Can we please stay on topic?

ChrisW: RDF processors wouldn't know that the subject of the triple is an IRI

<sandro> PROPOSED: rif systems SHOULD NOT accept RDF graphs containing the rdf:text or rif:iri data types

<AxelPolleres> in the end, it seems we agree on that, jos :-)

Sandro: Systems should issue a warning, and not silently ignore

<AxelPolleres> ... I was just going one step further and suggesting we even disallow rif:iri and rdf:text as datatypes in our pres syntax.

Sandro: I agree that we should say the meaning is not defined, but it's important that systems give a warning

ChrisW: We don't really give that kind of guidance in the specs (warnings)

<josb> PROPOSED: RIF-RDF combinations are not defined in case rif:iri or rdf:text are used in the imported RDF graphs

<AxelPolleres> +1

ChrisW: Does anyone object to Jos' and Sandro's proposals?

<sandro> +1

<Harold> +1

ChrisW: We can pass this resolution next week if there are no objections

AxelP: We should check with Andy Seaborne that this addresses his concerns

<josb> rdf-owl

sando: Yes, Andy S. will want to see the text in the relevant RIF specs, when we have it ready.

AOB

ChrisW:Adjourned