W3C

- DRAFT -

RIF-OWL Coordination Telecon

11 Dec 2008

Agenda

See also: IRC log

Attendees

Present
Boris Motik, Chris Welty, Christine Golbreich, Dave Reynolds, Ivan Herman, Jos de Bruijn, Sandro Hawke, Stella Mitchell, Zhe Wu
Regrets
Alan Ruttenberg, Ian Horrocks, Jeff Pan, Uli Sattler
Chair
Sandro Hawke
Scribe
Stella Mitchell

Contents


 

Sandro: Goal of this meeting is to figure out the tasks and who will do them, but not to dig completely into all the technical details
... four topics of coordination, the first, rdf:text, is probably simple

rdf:text

Sandro: Public comments for this are directed to the public OWL list

ChrisW: Ask editors of rdf:text if they are willing to be the coordinators of public comments

Sandro: In terms of last call and dependencies, both OWL specs and RIF specs will be dependent on it.

Boris: Is it OK to say in the OWL specs that we sppport the rdf:text datatype, and if the definition of the datatype changes later that will be OK since we are just pointing to it in an opaque way. This would make the OWL spec not dependent on the rdf:text document -- and I think this comment applies to the other datatypes also.

DaveR: rdf:text is a different case from other datatypes

Boris: When you say you change rdf:text, you are not changing the satisfiability of any document

DaveR: Yes, it would be an observable change. Andy Seaborne sent an email related to this

<DaveReynolds> Andy's message: http://lists.w3.org/Archives/Public/public-rdf-text/2008OctDec/0032.html

Ivan: I don't see the problem

Sandro: Andy's email above sent to the public rdf:text mailing list shows the problem

<sandro> sandro; we need rdf:text to get to rec before anything that depends on it

RIF OWL&RDF compatibility

<sandro> http://lists.w3.org/Archives/Public/public-rif-wg/2008Dec/0046.html

JosB: Summarizing the above email about changes to RIF, RDF and OWL compatibility document to account for OWL 2
... I made 5 proposals, labelled P1 through P5, in the email

Sandro: I don't fully understand the relationship between OWL 1 full and OWL 2 full
... but I tentatively agree to proposal P1

ChrisW: There was a change to OWL full in OWL 2, but we believe it is insignificant, is that right?

JosB, Boris: yes, there are no comprehension conditions in OWL 2, but not having these is not a real limitation for OWL 1 users, so we don't need to account for them in the RIF, RDF and OWL compatibility document

<DaveReynolds> Similarly I see no problem with P1

<sandro> sandro: sounds like P1 is fine

JosB: Summarized P2 and P3 from the email

<sandro> sandro: In OWL 2 you can't signal that you're not in OWL 1, so year, P2 and P3 make sense.

Boris: P2 and P3 are OK with me

Boris: Regarding P4, what are the IRIs of profiles?

<sandro> http://www.w3.org/2005/rules/wiki/SWC#Importing_RDF_and_OWL_in_RIF

JosB: Explaining IRIs of profiles. reference above.

Sandro: Note that these are not like OWL profiles

JosB: Does anyone disagree with P4?

Sandro: Do we still need the annotation profile?

JosB: No, would drop it.

Sandro: Regarding what syntaxes can be imported: the conformance clause for OWL says everyone must to implement RDF serialization for OWL and they may implement the other ones

<sandro> sandro: I think leave it RDF/XML, but maybe add a note about other syntaxes.

JosB: I don't have a strong opinion about allowing other syntaxes to be imported

JosB: summarizing P5

<sandro> jos: "OWL DLP" would migrate to "OWL 2 RL"

Boris: What is meant by a combination?

JosB: clarifiying combination as defined in RIF, RDF and OWL compatibility document

<DaveReynolds> Agree with P5 too

<sandro> P5 sounds good...

ChrisW: Why should DLP be dropped?

JosB: OWL 2 RL is sort of the same thing

ChrisW: But there are differences so why should we drop DLP? Most OWL implementations are currently OWL 1

JosB: I made up this DLP, it's not quite the same as the one you are thinking about that has been implemented

<sandro> jos: no datatype support in Horrocks et al DLP. that's one of several differences.

<DaveReynolds> +1 with Jos

<ivan> +1 with Jos

ChrisW: I'm not sure about dropping the DLP section from RIF, RDF and OWL compatibility document, I need to think about it more

Zhe: When I started in the OWL WG, we had a DLP but the WG decided to drop it, and then later OWL 2 RL was defined, so I support dropping DLP

Sandro: We'll investigate before deciding

The list of datatypes (aside from RL)

<sandro> http://www.w3.org/2005/rules/wiki/DTB#Symbol_Spaces

<sandro> http://www.w3.org/2007/OWL/wiki/Syntax#Datatype_Maps

<DaveReynolds> http://www.w3.org/2005/rules/wiki/OWLRL#Datatypes_supported

ChrisW: The two WGs should coordinate on the set of datatypes, there is no real rationale for having different sets in RIF and OWL

Boris: It's not just the list of types, but we have adapted the semantics of some of the datatypes, e.g. for double (and I could give other examples and details)

Sandro: From what I understand, the same reasons should apply to RIF, and so RIF should use the same definitions

<sandro> sandro: It sounds like there's nothing OWL specific here.... so RIF should also use owl:real, etc?

Boris: RIF has casts between datatypes, and OWL does not

<sandro> boris: imagine the weight property has range integer, and then someone gives a value of "70"^^xs:double --- that's inconsistent.

<sandro> boris: In RIF you can do a cast, which allows you to hack around this situation.

ChrisW: OWL doesn't support any functions, is that right?

Boris: yes, that's right

ChrisW: We could adopt a common set of datatypes, and OWL wouldn't include the builtins and RIF would include them

DaveR: Boris, are you saying that owl:real isn't separated from the integers?

<sandro> boris explains owl:real and owl:realPlus

Boris: owl:real is the umbrella for all the numeric datatypes

Boris: We chose these datatype definitions to try to be more user friendly

ChrisW: I'm trying to understand if there needs to be an actual difference in the set of datatypes
... or whether we can both have the same datatypes, and then RIF supports builtins while OWL doesn't

<DaveReynolds> dave: don't understand how "1.1"^^owl:real can be both a double and decimal, they are different

ChrisW: So, owl:real is a superclass?

Boris: Yes

ChrisW: Ok, so there is a difference in some of the datatype definitions
... OWL approach breaks XML schema compatibility

Boris: We did talk to XML schema people and they weren't averse to this, but rather supported it

<sandro> meeting extended until 20 after the hour.

ChrisW: So that feedback from XML schema group may help address the concerns of the production rule representatives in RIF

JosB: These issues with value spaces are subtle and I would be OK with changing to the way OWL is doing it. But I think the long list of datatypes is a problem

DaveR: owl:real sounds like a problem to me. people use decimal and double for specific reasons
... when you express something you need to know what it is

Boris: You do always know what it is
... small problem might be when you say the range must be an integer and then put a double constant there that is actually an integer
...In OWL we say you have not violated the range constraint in that case

<sandro> boris: The only question is when you do class reasoning on types....

<sandro> sandro: in RIF this comes up with is-this-an-integer applied to "70"^^xs:float or "70"^^xs:decimal.

Sandro: RIF needs a test case about this, to get feeback from the WG

JosB: What Sandro wrote above, in OWL would you interpret those as different objects?

Boris: No, we interpret them all as the integer 70
... but 0.1 double is not the same as 0.1 decimal, because 0.1 double gets rounded

<sandro> boris: "0.1"^^xs:float is NOT the same as "0.1"^^xs:decimal, because of rounding in the internal representation. We don't lose any precision.

<sandro> boris "70"^^xs:float and "70"^^xs:decimal are IDENTICAL in OWL -- they are both the number 70.

Boris: XML schema defines equality differently from identity

DaveR: If you put in value that's larger than the mantissa for xs:float, what happens?

Boris: It would follow the mapping giving in XML schema, I don't know what that is off the top of my head

<ChrisW> is 100000000000045 (assuming that is beyond the range of float) a *float*

ChrisW: Question - is the number above considered a float?

Boris: Yes, it is. but it might get rounded into another float

<sandro> boris: This gets messy, comparing doubles with integers, etc, but we did manage to implement this in Hermit.

<DaveReynolds> The test case is whether "100000000000045 "^^xsd:float = "100000000000045"^^xsd:integer, the answer should be no.

<Zhe> or "1.0000000000000001"^^float = "1"^^integer, answer is yes

OWL 2 RL

Sandro: Here are the items for this topic from the agenda:

<sandro> -- aligning the list of datatypes

<sandro> -- providing the rules as a RIF Core document

<sandro> -- any issues with the ruleset itself

<sandro> -- rules/code to check the ontology

DaveR: First item: since datatypes don't align, we couldn't express OWL RL in RIF

<sandro> DaveReynolds: it would be ideal if the OWL-RL datatypes were the intersection of OWL and RIF-Core datatypes.

Sandro: It will be easier to reduce the list of datatypes in OWL-RL than in the other OWL profiles
... customers would want RIF and OWL to be aligned

DaveR: Normalized strings

JosB: Why in OWL-RL can you not allow datatypes with finite value spaces? (something about existentials)

Boris: maybe in OWL-RL that restriction is not necessary
... we do need it in EL and QL, but you are right, maybe not needed in RL

Sandro: DaveR, are you willing to see if we can get these extra datatypes added to RIF Core?

DaveR: I think it will be mostly up to Axel - I see no value in having things like ncname

Boris: We kept it for consistency, so we didn't have to explain why we excluded it, and it's not hard to implement anyway

DaveR: RIF took the opposite approach: each inclusion had to be justified. It's work and time to implement them, even if it's not difficult

JosB: owl:rational would be something completely new for RIF

Sandro: RIF needs to look at the list of OWL-RL datatypes and see which ones can go in RIF core and then ask OWL to remove the other ones

ChrisW: Does OWL 2 support all the RIF datatypes?

Boris: There are two XQuery duration related ones that we don't support

Sandro: We need to decide what to do with the "OWL 2 RL in RIF" document

<sandro> DaveReynolds: I'm fine with my document being folded into Jos'

<sandro> jos: my embedding stuff does not operate on T(s,p,o) but on translation to RIF. very different.

JosB: The embeddings in mine and Dave's documents are different. I sent email about this.

ChrisW: In DaveR's document there is the RIF-Core rule implementation of OWL 2 RL and there is a lot of background information. How about just taking the RIF Core implementation and making that the OWL-RL rules?

<sandro> bmotik: We're perfectly aware that a naive implementation of the OWL RL rules will have poor performance. But we wanted the semantics to be very clear.

<sandro> bmotik: eg quadratic number of literals, but you'd need builtins and NAF, etc.

<sandro> bmotik: and we didnt want to go there.

ChrisW: I don't understand your point. I'm suggesting you express the OWL-RL rules in RIF Core presentation syntax.

Boris: Ok, I understand the question. I'm not sure right now, I need to consult with others.

ChrisW: I think if we solve the datatype issues, then it should just be a small change to the syntax

DaveR: OWL uses ellipsis in their specification of the rules; that makes it easier to read, but less explicit about what to implement

<sandro> Zhe: I don't want to take out the RDF-oriented rule in the OWL-RL spec, but I like adding RIF stuff.

Boris: My personal opinion is that changing the actual ruleset would be painful for OWL and require extensive negotiations, but changing the syntax may be OK

<ChrisW> "Life IS pain, princess. Anyone who says otherwise is selling something" - Princess Bride

<DaveReynolds> :-)

Sandro: adjourned

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/12/11 18:32:36 $