SV_MEETING_TITLE -- 16 Jul 2008

<IanH> ScribeNick: bmotik

Yes

I'll try

alanr: No agenda amendments

<rob> looked reasonable to me

<IanH> Minutes look good to me

PROPOSED: Accept previous minutes (9 July)

<pfps> they have all the requisite parts - their veracity I can't determine

RESOLUTION: Accept previous minutes (9 July)

3F2F

alanr: Please register whether you'll be or not at 3F2F
... Please give us feedback about the agenda

<IanH> Lot of background noise, including crying baby?

action item status

alanr: I can't invest more time into ACTION-159 , so let's drop it
... I produced input for ACTION-166

pfps: I don't see any rationale to using two files in the write-up

alanr: We are discussing here the completion of the action, not the contents

pfps: I consider the action finished

due and overdue actions

alanr: Jie has initiated discussion about ACTION-150

ivan: Someone from our side should check owl:internationalizedString

alanr: Michael, what is the status of the OWL-Full semantics?

<m_schnei> OWL Full: http://www.w3.org/2007/OWL/wiki/FullDraft

mschneider: There is a draft
... It is half-finished

alanr: Where do we stand? How far are we from the working draft?

mschneider: I have already added most of the semantic conditions.
... There is some editorial work and some open issues.
... The import question is open.

alanr: Can you produce a single document by the F2F?

mschneider: The present document can't be turned into a working draft by the F2F -- not enough time.

alanr: It would be great to have a document ready for review by 3F3F.

mschneider: I hope so.

alanr: ACTION-157: I have a response from Judy Brewer
... ACTION-157 gets postponed

bijan: I could take it around to Robert Stevens

<ivan> bijan++

alanr: That would be very good
... Please add an action for that

<bijan> ACTION on Bijan to test our documents for accessibility with Robert Stevens

<trackbot> Sorry, couldn't find user - on

<bijan> ACTION: Bijan to test our documents for accessibility with Robert Stevens [recorded in http://www.w3.org/2008/07/16-owl-minutes.html#action01]

<trackbot> Created ACTION-168 - Test our documents for accessibility with Robert Stevens [on Bijan Parsia - due 2008-07-23].

alanr: Uli, what is the status on the top/bottom roles?

uli: The action is done

<bijan> He's supposed to send email about it

bmotik: I have already added these roles to the document

alanr: Just send an e-mail documenting it
... Should we close ACTION-165 as withdrawn?

PROPOSED: Close ISSUE-31 as withdrawn

<ewallace> +1

<m_schnei> +1 (FZI)

<alanr> +1

<bijan> +!

<pfps> +inf

<ivan> +1

<IanH_> +1

<bijan> +1

<Zhe> +1

<uli> +1

<Achille> +1

<bcuencagrau> +1

RESOLUTION: Close ISSUE-31 as withdrawn

<IanH_> I have to hang up and call in again

Proposals to resovle issues

<IanH_> can't unmute myself

alanr: Ian, could you tell us how to resolve ISSUE-67?

<m_schnei> ok

ianh: We already decided to use owl:Axiom instead of rdf:Statement
... There has been no discussion for a long time, so it seems to me that the issue has been resolved.

mschneider: My statement that "there is no problem" referred to something else
... This is a question that I can't decide and I asked people at FZI

mschenider: RDF people dislike reification

mschneider: Feedback from FZI: There was noone in favor of reification; a few people said "either way"; a few people were against
... My proposal is to use a shadow vocabulary

ianh: I don't have a problem with that
... I don't think it is reasonable to object to resolving issues by arguments of the sort "I don't quite like it...because?"
... Shadow vocabulary seems fine

<alanr> michael are you coming back on?

alanr: Bijan, have you got a general comment?

bparsia: I wanted to ask Michael about his polling methodology
... We introduced vocabulary for property punning which gives additional functionality
... We now need to introduce new vocabulary for no new functionality

Zhe: I wanted to ask whether the base triples should be included into serialization?

alanr: This is a separate issue; should go on the Issues list
... I don't think it is good to rule out the RDF shorthand

<alanr> acn IanH_

ianh: Let's just use the shadow vocabulary and be done with it.
... Is there any reason not to do that?

PROPOSED: Close ISSUE-67 by introducing new shadow vocabulary

<ewallace> +1

<IanH_> +1

<JeffP> +0

<alanr> -0

<Achille> 0

<uli> 0

<ratnesh> 0

<pfps> 0

<ivan> 0

<Zhe> 0

<bijan> -0.00001

<bcuencagrau> +1

<m_schnei> +1 (FZI)

<bijan> I don't like it, but I'm broken on this so don't care :)

<m_schnei> sorry, my line broke down

RESOLUTION: Close ISSUE-67 by introducing new shadow vocabulary

bmotik: We'll add owl:subject, owl:object, and owl:predicate
... I'll change the spec accordingly

The state of OWL-R and OWL-R DL/Full unification

alanr: There is a proposal from Boris

mschneider: There is a proposal from Boris, but I don't think I understand it
... As far as I understand, all the triple rules will remain

mschenider: Is this still true?

bmotik: yes

mschneider: How do I understand on the OWL-R DL side?

mschenider: Until now, there were two parallel specification of two langauges.

mschneider: These two languages had not much in common
... Is it that we'd need to parse the triples, check the syntax, and if that's accepted, then one goes to the semantics document?

<bcuencagrau> I can scribe

<bcuencagrau> bmotik: currently, we have two languages which are different

<bcuencagrau> bmotik: this is undesirable

<bcuencagrau> bmotik: the ideal situation would be to define the profiles in exactly the same way

<bcuencagrau> bmotik: that is, as syntactic fragments of OWL 2

<bcuencagrau> bmotik: an RDF graph falls within any of the fragments if it corresponfs to an ontology in the functional syntax according to the RDF mapping

<bcuencagrau> bmotik: the rules in OWL-R could be used directly in an implementation

<bcuencagrau> bmotik: no need to look at the OWl Full semantics

<bcuencagrau> bmotik: then, we would unify the language

<bcuencagrau> bmotik: Ivan has raised some objections

<bcuencagrau> bmotik: what if a graph does not fall within OWl R

<ivan> s/OWI/OWL/

<bcuencagrau> bmotik: in my opinion, the user should be warned

<bcuencagrau> bmotik: but still the rules could be fired

<bcuencagrau> bmotik: but not with the guarantees that you would have within OWL-R

mschneider: I have no objection to this

<bcuencagrau> bmotik: an implementation could also apply the rules to ontologies that do not fall within OWL-R

mschneider: The question for me is what is the DL semantics of ...
... The current rule set has subproperty chains
... You need to support subproperty chains

<bcuencagrau> bmotik: we do support subproperty

bmotiK: I thing you are wrong

<bcuencagrau> chains

mschneider: I'll check

<bcuencagrau> yes

<bcuencagrau> bmotik: OWL-R DL mimicks everything that is in OWL-R Full

<bcuencagrau> bmotik: both OWL-R DL and OWL-R Full have been guided to allow for rule-based implementations

<bcuencagrau> bmotik: the intention was the same for both

<bcuencagrau> bmotik: they both should support the same, and if not it is a bug

alanr: Could Zhe or Ivan say something?

ivan: I'll try to summarize the discussion
... I understand the whole mechanism that Boris has descirbed
... The problem is the marketing side, rather than the technical side
... If we do this way, then RDF users and implementors use a clear possibility to reference something that is clearly standardized
... The problem is that there are "almost" OWL-DL graphs, that can be managed by the rules
... I don't care whether you call this a "Profile"; however, we need a clear reference

<alanr> two statements worth verification : "these are two very different languages" "there are no issues with the list vocabulary and the rules"

<bcuencagrau> bmotik: it is a fair summary

Zhe: I don't have too much new stuff to say
... I'm happy with the spec as it is
... But I can see that the unification might be good
... I tend to agree that we need some name from a markeeting perspective

<Achille> +1 for ivan

alanr: Michael said that these are two different langauges; Zhe, is this your sentiment as well?

Zhe: I don't see them as totally different languages

ianh: I was quite surprised ot hear Ivan come up with the marketing argument
... The current situation actually seems pretty bad from an RDF implementation point of view
... I would imagine that many of the existing implementations basically try to implement as much of OWL Full

<m_schnei> I remember that I originally saw two *very* different languages, having different language constructs, but this might have changed over time

ianh: These implementations would become invalid OWL_R/RDF implementations

<pfps> +1 to Ian's comment

ianh: You would not be allowed to add additional rules, as you would become unsound
... If we went with the current proposal, all existing rule-based implementations could say that they are valid OWL-R implementations
... This seems a big advantage for the DL community
... The name that people have for describing their system is "OWL-R".
... What is OWL-R? It is a fragment of OWL-Full.
... I think that people prefer the current situation because they don't understand all the consequences of the current spec.

ivan: The vendos usually something as PDFS++, OWL-Prime...
... All of the implementors implement subset of the current OWL-R.
... The message I got from people is that they'd like to say whatever they implemented is a standard

<bcuencagrau> +q

ivan: The problem is that there would be several OWL-R graphs that OWL-R implementations would not accept

ianh: Ivan, you said that most people implement a subset of these rules; but then, they are not OWL-R reasoners

ivan: Yes, but they want a standard

ianh: Most people implemented a superset, but then, they are not a standard

<m_schnei> since owl R has sub property chains, i very much doubt that any triple rule implementation is a superset of owl r

ianh: Implementors usually want to implement more
... If we changed their spec, this would prevent people from implementing more

alanr: Suppose you add a rule to OWL-R that is unsound w.r.t. OWL Full
... Would that be considered OWL-R conformant?
... The current spec is permissive in the sense that anything would be OWL-R comformant

<Zhe> which rule?

ianh: You would add as many rules as you like

bparsia: I am not as convinced by the marketing argument
... It is imporant to focus on a subset where we can really understand what the functionality is
... We should allow people to do extensions
... It is important for the users to understand what each construct means in terms of the language

bcuencagrau: If we do this as proposed currently, you need to support at least the specified rules

<alanr> back in a sec

bcuencagrau: You could add as much as you want, you would not any semantic guarantees, but you can add it it the users really need it

-q

ivan: I don't understand how this all issue of extensions came into the discussions.
... According to the planned spec, there will be a set of rules, and if I just implement this set of rules and apply it to the set of graphs, then I implement not exactly OWL-R but a bit more

<bijan> More than OWL-R is an extension yes?

ivan: This is what bothers me
... I'd like to be able to say to the world what exaxctly I'm implementing

<bijan> We have a nice syntactic criterion...you handle what's in by the parser

ivan: I would like to signal the fact that I'm accepting more than OWL-R graphs

mschneider: If a reasoner produces inferences that are not entailed by the languages, then the reasoner is unsoud
... If a reasoner produces more than OWL-R, then the reasoner is unsound

<IanH_> NOT TRUE -- because this only happens for graphs that are *outside* the syntactic fragment

alanr: We should resume the discussion next week

<IanH_> Such reasoners are SOUND for OWL-R

Normative datatypes

<pfps> see http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0306.html

<bcuencagrau> bmotik: proposal for datatypes

<bcuencagrau> bmotik: we would have numbers^+

<bcuencagrau> bmotik: which contains the reasl plus +inf, -inf, etc

<bcuencagrau> bmotik: then we would have the `numbers', which would contains the reals

<bcuencagrau> scribe lost

<bcuencagrau> sorry, I lost the thread

<pfps> I think that Boris means "minimally conforming" as in the XML Schema spec

<pfps> This is all in the message, so I don't think that Bernardo needs to scribe everything.

<IanH_> boris: implementers discretion as to how many decimal digits to be supported

<bijan> There's an email about all this

<bcuencagrau> ok

<bcuencagrau> bmotik: all the information is in the email

<IanH_> http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0306.html

alanr: Evan, you had some question about the floats?
... Could you comment on that?

evan: Are computational effects going to cause problems?
... Will be get ropunding problems?

<alanr> 1) Can you use float constants to specify real facets?

<rob> "0.1"^^xsd.float != "0.1"^^xsd:decimal

<alanr> 2) Any reason not to have base64binary with octet value space?

<bcuencagrau> bmotik: every constant will have a precise interpretation

<bcuencagrau> bmotik: floats will be interpreted as in the IEEE spec

alanr: You could use a float contant to specify a facet on owl:real?

bmotik: Yes, no problem.

<bcuencagrau> bmotik: every constant just maps to one value

alanr: You couldn't get more precision by using extra digits?

bmotik: No, there is no problem.

<bcuencagrau> bmotik: we could have it as a synonym

<bcuencagrau> bmotik: value spaces will be synonyms

<bcuencagrau> bmotik: I didn't include it for redundancy

Zhe: In your proposal, would the value spaces of xsd:float and xsd:double be disjoint?

<bcuencagrau> bmotik: no

<bcuencagrau> bmotik: that is Jena's problem

<alanr> in that case they map to same value

<bcuencagrau> bmotik: you are comparing a double with a float

<bcuencagrau> bmotik: that could be implemented correctly

<ewallace> value comparison was exactly my issue

<bcuencagrau> bmotik: the problem is not in the disjointness

<bcuencagrau> bmotik: java would map 0.1 float into a 32bit representation

<bcuencagrau> bmotik: it would map 0.1 double into a different number

<bcuencagrau> bmotik: it doesn't seem to be a SPARQL problem

<bcuencagrau> bmotik: probably it is an RDF problem

<alanr> comparison of .1d, .1f has different result in real space then when promoting to double

alanr: I think that there might be a point on the comparison of numbers
... I believe that rounding of a float to a double and then comparing it to a double is not going to give you the same thing as compariong values in the value space
... We are promoting to owl:number, so implementations can't use IEEE semantics

achille: We should stay compatible with XML Schema
... Why are we departing from XML Schema?

uli: I hear all these concerns about compatibility.
... I'm sure that we'll be compatible with XML Schema; in fact, we won't be able to tell the difference

<bcuencagrau> bmotik: XML Schema has benn designed for different purpuse

<bcuencagrau> bmotik: in OWL you can quantify over values

<bcuencagrau> bmotik: in XML Schema it is pointless whether a value space is continuous or not

<Achille> but they also care about comparisons

<bcuencagrau> bmotik: in OWL we need to define behavior of data ranges during reasoning

<alanr> (maybe too close ;-)

<bcuencagrau> bmotik: and hence go beyond XML Schema

<bcuencagrau> bmotik: in OWL you can distinguish whether the value space is discreet or continuos

alanr: We are almost out of time
... We should see which areas of the proposal are uncontentious

ivan: I had two points

<bcuencagrau> bmotik: I don't know

<alanr> it does say that

<pfps> in XML schema double and float have disjoint values spaces

<rob> they are colored differently, but defined mathematically

<alanr> but they say that implementations can do cross comparisons

ivan: Have you checked what XML Schema says about value spaces?

bparsia: 1.0 spec says that the value spaces are disjoint. 1.1 says that implementations can interpret this as they want

<alanr> SPARQL would be incomplete wrt to OWL. no surprise

<ivan> http://lists.w3.org/Archives/Public/public-owl-wg/2008Jul/0223.html

ivan: The guys who looked at the internationalize string datatype described an alternative.
... Essentially, one wants ot define a whole family of datatypes by saying that each datatype would be identified by a different URI.
... what is the relationship?

<bijan> That doesn't seem workable

+1 to bijan

Achille: I still think that XML Shema is a standard. There is clearly the need for comparing datatypes from different registries.
... Applications might be broken if we depart on this

<Zakim> bijan, you wanted to reply to achille

<Zhe> +1 to Achille

bparsia: I've been on both sides of the disjointness issue
... Reasoners differ on this

<alanr> ditto xfunction, xquery

<rob> all Cerebra's users were sensitive to it

bparsia: It seems to me that people are not sensitive to this

<rob> it was reported as a bug several times

<alanr> We can cite this email stream

bparsia: I was shocked that the XML Schema guys thought there was no problem in making them disjoint
... I've switched from disjointness to believeing that people don't care that much about disjointness
... We'll have to make a pick, and we'll have to pic something

<Achille> We have people we have implemented it in IBM stack

<pfps> I seem to remember that the disjointness in XML Schema Datatypes 1.0 was in response to an email message that I sent pointing out that, at the time, the XML Schema documents clearly stated that xsd:float and xsd:integer did *not* have disjoint value spaces.

alanr: I'll try to test agreement

<Achille> I will like to talk to them about their position on this issue

alanr: owl:number(Plus) seems like a good idea
... I've heard questions from implementors regarding rationals

<pfps> That's not an implementation *restriction*!

alanr: The restrictions on integers seem uncontroversial
... Dittoxsd:decimal
... Floats seem controversial
... We need coordination regarding strings
... The empty language tag seem to address some of the problems of previous proposals

alan: boolean, hexDecimal seem OK

alanr: Date/time need more discussion
... It seems to me that we've made quite a lot of progress
... There are not as many open issues

<pfps> +1 to meet next week

alanr: Should we have a meeting next week?
... Ian and I think yes.

<uli> bye

<Zhe> bye

<IanH_> I can do it

<IanH_> I know it very well!

alanr: Please send an e-mail about it.

<ratnesh> bye

- DRAFT -

SV_MEETING_TITLE

16 Jul 2008

Attendees

Contents