These minutes have been approved by the Working Group and are now protected from editing. (See IRC log of approval discussion.)

See also: IRC log

Martin Dzbor: Ian I'm here, should I be typing? I guess I am fairly to the top...

(Scribe changed to Martin Dzbor)

Ian Horrocks: we need to set this scribing business up on mailing list before the call...

Agenda amendments

Bijan Parsia: If there's primer or restructuring comments I'd love to hear them
Bijan Parsia: as an agenda amendments

PROPOSED: accept last week's minutes as per

Peter Patel-Schneider: -1, and I read them
Bijan Parsia: Peter points out that there is inappropriate material in those minutes. I post an example here: """Aren't Wikis fun"""
Bijan Parsia: """Bullwinkle: Watch me pull a rabbit out of this hat!"""
Bijan Parsia: """Rocky: Bullwinkle, that trick never works!"""
Bijan Parsia: """Bullwinkle: I gotta get me a new hat!"""
Bijan Parsia: These seem to have been inserted by the scribe (Jim Hendler). I.e., they weren't in the log and they appear in the only edit Hendler did.

Ian Horrocks: do the minutes need more cleaning up?

Martin Dzbor: +1 (accept)

Ian Horrocks: let's put it off until next week, ask Jim to clean it up

Ian Horrocks: let's treat the minutes as not accepted yet, we return to them at the next call

Ian Horrocks: Manchester minutes are also postponed for later? or not?

Peter Patel-Schneider: still missing pointers to talks in F2F minutes

ACTION: Alan to add links to presentations to F2F minutes

Bijan Parsia: Perhaps some other volunteer to help with the F2f minutes?
Bijan Parsia: Alan already has to do a lot
Bijan Parsia: As do I, but if no one else will volunteer to do this, then I'll do it. Bleah.

PROPOSED: Accept F2F1 minutes with presentation links being added later

Sandro Hawke: +1 accept minutes

Zhe Wu: Jeff Pan: yes

Alan Ruttenberg: links and presentations were communicated via mailing list

Alan Ruttenberg: s/-;)/;-)/
Jeff Pan: jeremy, thanks!

PROPOSED: Accept F2F1 minutes with presentation links being added later

RESOLVED: Accept F2F1 minutes with presentation links being added later

Jeremy Carroll: My presentation is linked from some minutes (may be last weeks) I will find the link and post again

Pending review actions

Ian Horrocks: most are in a good shape

Peter Patel-Schneider: all pending review actions look OK

Ian Horrocks: Bijan has completed his action, Bijan comments?

Bijan Parsia: three actions concluded, scenario is under control...

Ian Horrocks: action for Jeremy, also completed?

Ian Horrocks: actions were completed adequately, so are there any problems with them? or should we close them?

? (guest): what we need to the with these actions pending review if we're happy with their conclusion?

Overdue Actions

Sandro Hawke: working on Action 43, in progress... no specific date yet

Sandro Hawke: will try to fix it by Jan 25th (?)

Bijan Parsia: It's done
Sandro Hawke: s/Feb 5th/Jan 25/

Ian Horrocks: Action 56 overdue is probably done -> Bijan says: has been rolled into n-ary proposal...

Bijan Parsia: action should be closed, more info to be circulated this week

Proposals to resolve issues

PROPOSED: close (as RESOLVED) Issue 29 (user-defined Datatypes: owl:DataRange vs rdfs:Datatype) as per

Ian Horrocks: peter refreshes what proposal is about

Michael Smith: asking about point 4 of the issue

Boris Motik: I didn't understand: has this been already implemented in the documents?

Peter Patel-Schneider: proposal is about moving from owl:DataRanges (as in current RDF mapping doc) to express user's datatypes to model them as instances of the RDF Schema class rdfs:Datatype; we checked rdf semantics, datarange is deprecated and rdfs:Datatypes makes it more consistent with the semantic web stack

Peter Patel-Schneider: PROPOSED: Issue 29 move from owl:Datarange to rdfs:Datatype

Jeremy Carroll: we used data range before, we may want to think about the past uses before changing this...

Jeremy Carroll: only noticed now, owl:DataRange is also used for sets of plain literals... see:

Peter Patel-Schneider: Hmm, I think that Jeremy's point needs thought

Ian Horrocks: let's have a look at the next item, Issue 73, that seems to be clearer...

Issue 73: (Should owl:Thing be necessarily infinite?) as per

Peter Patel-Schneider: +1 to reject 73
Alan Ruttenberg: I raised issue and concur on rejection
Bijan Parsia: +1 to reject 73

Ian Horrocks: this seems to be unanimous, people agree to reject

PROPOSED: close (as REJECTED) Issue 73 (Should owl:Thing be necessarily infinite?) as per

Michael Smith: +1 to close as rejected Issue 73
Achille Fokoue: +1 to close
Achille Fokoue: as rejected
Bernardo Cuenca Grau: +1 to close as rejected
Carsten Lutz: +1

Doug Lenat: +1
Zhe Wu: +1

Jeremy Carroll: if nobody can support Jeremy's position, Jeremy notes his opposition, but sees no point in continuing debate

Boris Motik: +1 to close issue as rejected

Bijan Parsia: is Jeremy's point an objection from HP? or what is its status...

Jeremy Carroll: this is NOT a formal objection. [Scribe assist by Sandro Hawke]

Jeremy Carroll: it's not a formal objection

Jeremy Carroll: there may be enough small problems like this, that it may total to a formal objection...... [Scribe assist by Sandro Hawke]

Ian Horrocks: close the issue, record Jeremy/HP voting against...

Ian Horrocks: ongoing discussion of this is not likely to get us to consensus. Jeremy seems to agree with this assessment -- he just wants a "no" vote recorded. [Scribe assist by Sandro Hawke]

Jeremy Carroll: maybe HP should review the vote against, but perhaps at the next publication stage

Ian Horrocks: due to an opposing vote, make sure we record everybody's voice, incl. abstaining

RESOLVED: close (as REJECTED) Issue 73 (Should owl:Thing be necessarily infinite?) as per

Ian Horrocks: moving to Issue 74, (Use the xsd namespace for the facet names) as per

PROPOSED: close (as RESOLVED) Issue 74 (Use the xsd namespace for the facet names) as per

Ian Horrocks: discussed last time, everybody seems happy along the above lines

Ian Horrocks: quick vote

Peter Patel-Schneider: +1 to resolve 74
Doug Lenat: +1
Michael Smith: +q to ask about scope
Zhe Wu: +1
Zakim: msmith, you wanted to ask about scope

Michael Smith: asking about the scope... there might be some contentious items...

Jeremy Carroll: Clarified all A-D

Ian Horrocks: discussed last time,

RESOLVED: close (as RESOLVED) Issue 74 (Use the xsd namespace for the facet names) as per

Discussion: 1. Blank nodes and Skolems (Issue 3)

Ian Horrocks: some discussion on the mailing list... Bijan, Jeremy to sum up?

Jeremy Carroll: (bijan first?)

Bijan Parsia: responded to Jeremy's msg.,

Bijan Parsia: starting from the beginnning, in owl 1.0 we could represent tree-like patterns of anonymous existentials...

Bijan Parsia: serialized as blank nodes

Bijan Parsia: RDF extensionally qualifies all b-nodes, which in OWL would mean undecidability

Bijan Parsia: possibly have them as syntactic sugar, to handle RDF graphs as users expect; more RDF graphs would be DL legal and the behavior of the reasoner would be more familiar

Bijan Parsia: Carsten proposed a spec. 'total' role to represent true extensionals; algorithm is for SROIQ, and it is correct. SROIQ has the true universal role.

Jeremy Carroll: (I'm behind on the universal proposal and existentials)

Bijan Parsia: objections, question?

Jeremy Carroll: discussed issue with colleagues, and it's clear that many implementation techniques use skolems... some may fail on entailing from bnodes... such failures not included in the conformance of the reasoner to the OWL semantics...

Jeremy Carroll: there were implementations in previous wg, that's why we defined certain checks only on consistency to get conformance... diff methods of implementation, can't mandate one...

Peter Patel-Schneider: wants to talk about what the OWL 1.0 specs imply

Ian Horrocks: is this the case that if we define conformance w.r.t consistency check, not being able to tell diff

Jeremy Carroll: basically yes, diff parts of rdf graph may correspond to dl constructs

Boris Motik: Jeremy, I didn't udnerstand that

Jeremy Carroll: b-nodes treated diff in owl-full = its semantics becomes more difficult

Bijan Parsia: not understanding what is meant by impl. techniques, skolemization is a common one, but we're proposing something stronger, so that some entailments hold,

Bijan Parsia: if we reason about abox, we recognize the items as individuals, as people expect should happen

Bijan Parsia: owl-full seems a bit hypothetical problem?

Bijan Parsia: need to reconcile arguments that in some cases keep the old approach vs. cases that change semantics (of owl full), which could break reasoners

Bijan Parsia: we're trying to bridge the gap between dl and full, at the cost of some abstract parts of the theory being left out

Boris Motik: reiterating Jeremy, whether we treat skolems as individuals or exist. variables, doesn't matter... as long as we maintain consistency criteria? correct?

Boris Motik: we may actually strengthen this, in rdf we can have b-nodes on syntax level

Alan Ruttenberg: can't tell the difference in owl1.0 afaik - needed negated property assertions ?

Boris Motik: what about b-nodes in entailed ontologies?

Boris Motik: treat b-nodes as existentials?

Boris Motik: if it's on the right hand side, possibly... if it's in the graph part, it's something else

Bijan Parsia: q+ to disagree
Carsten Lutz: What is the opposite of "b-node in the data"?

Ian Horrocks: interesting thing = worried about the case when everything is skolemized, incl b-nodes?

Bijan Parsia: Good point by Ian....though they are already skolemized!
Bijan Parsia: Carsten, tbox axioms use bnodes for syntax
Boris Motik: q+ for Jeremy
Bijan Parsia: e.g., C subClassOf [a restriction; onProperty P; someValuesFrom C]

Jeremy Carroll: coming from owl-full implementation has some consequences... shouldn't we be worried that owl full would make non-entailments if this was adopted?

Peter Patel-Schneider: hmm, skolemizing syntax on the RHS would have grave consequences
Carsten Lutz: Bijan Parsia: in which case does this happen?
Bijan Parsia: the brackets are bnodes
Bijan Parsia: Carsten, pervasively...any class expression really

Ian Horrocks: when skolemizing individuals would cause problems... it's a thing what other people talk about?

Alan Ruttenberg: Jeremy Carroll: Do I understand that you are worried that Full would make non-entailments if this was adopted?
Alan Ruttenberg: or rather without doing more work in Jena

Bijan Parsia: thought that in owl-dl there is a way of skolemizing syntax... we already use, everybody using rdf is already using those things

Jeremy Carroll: wants to respond to boris's question?

Bijan Parsia: in SPARQL, b-nodes can be in answers and can be treated as skolems...

Peter Patel-Schneider: if you skolemize syntax, then john in >=1 C won't entail john in >=1 C in OWL Full

Bijan Parsia: supporting sparql syntax over ontologies, it matters a lot how we treat it

Bijan Parsia: might not be variables, just funny renaming conditions

Zakim: bijan, you wanted to disagree

Bijan Parsia: this is an example of rdf syntax which is highly visible and has impact

Michael Schneider: FZI is pro "bNodes as skolems" in /DL/

Alan Ruttenberg: wants to clarify = concern is because of role implementation that generates entailments in owl-full... would be incorrect if skolemization is used?

Ian Horrocks: less complicated if considering skolemizatin as syntax?

Jeremy Carroll: answer boris... how jena treats b-nodes on the RHS

Jeremy Carroll: implemented to satisfy test cases = skolemized on the LHS, on RHS it's variables .......

Bijan Parsia: really?
Zakim: jeremy, you wanted to respond to boris's question?

Boris Motik: why conversion of RHS in sparql? is the diff betwen bijan's and jeremy's view in schema part?

Bijan Parsia: data counts... users may work on expectation that we take RHS and LHS, maintain mapping, entail, get them back

Bijan Parsia: no issue with schema part...

Jeremy Carroll: main concern is to change underlying semantics

Jeremy Carroll: not sure how changing semantics changes classificationa apps... why change semantics?

Bijan Parsia: It matters for counting

Ian Horrocks: classification may not make entailment visible... only uses satisfiability

Boris Motik: assume we're defining b-nodes in data as skolems... how to implement? not a matter of changing semantics doc, maybe a change for parsing doc?

Boris Motik: every b-node should be mapped onto an element of graph -> individual, etc.

Bijan Parsia: I am happy with Boris's proposal to move it to parsing
Jeremy Carroll: q+ to respond to parsing suggestion ....

Boris Motik: this may provide solution = on semantic level, b-nodes are existential vars, but there can be a switch to say that when parsing rdf, they should be treated as skolems... up to user/app to decide... could be?

Michael Schneider: boris, you have at least the testcases (normative document): you can have testcases for non-entailments for skolems, which would be entailments for existentials

Alan Ruttenberg: how this is visible... practical reasons, removes requirement and b-node as a tree, allows more flexibility,... intended meaning in most cases is skolemization...

Boris Motik: Alan, you have inequality

Alan Ruttenberg: we don't see diff between skolems and existentials in owl 1.0... we need a negated property on individuals to see it??

Jeff Pan: q+ to ask how to explain the difference to users

Ian Horrocks: doesn't seem to be so diff... skolemizing on RHS should be visible even in owl 1.0

Bijan Parsia: agrees with alan that they are user-visible

Bijan Parsia: Q to Jeremy = what means "compelling argument" for/against something? e.g. many users wanting to use rdf graphs in owl reasoners, this is a powerful case, why not compelling

Bijan Parsia: similarly, sparql relationships, etc. = these are fairly important cases

Zakim: jeremy, you wanted to respond to parsing suggestion ....

Jeremy Carroll: to bijan first... what I haven't seen is how reworking semantics affects skolemization, is it necesary? (???)

Bijan Parsia: how to propose arbitrary b-nodes from rdf, what should they give/

Jeremy Carroll: no answer at this point...

Jeremy Carroll: to Boris.... finding that position of a value, at this moment...

Jeremy Carroll: there is some rationale behind it

Jeff Pan: maybe somebody can explain what this means for the users/end users... so that more people can join the debate?

Alan Ruttenberg: q+ to say fwiw, it's always harder to explain existential semantics in my experience
Doug Lenat: (And do that between now and next week, offline, and revisit it next week?)

Ian Horrocks: lot of explanation of this, maybe a bit technical...

Bijan Parsia: Basically, jeremy, any way that tells me how to handle in an rdf sensible way arbitrary patterns of bnodes meets my interest in this

Jeff Pan: if people write owl 1.1 axioms, what are the key diffs for THEM

Bijan Parsia: I have no need to change the semantics per se
Bijan Parsia: I.e., my interest isn't in changing the semantics, but service this interest
Boris Motik: I already did something like this

Ian Horrocks: could Jeff, Jeremy prepare some examples? or Boris? or someone else?

Alan Ruttenberg: We will need such an explanation if we make the change for the documentation - so effort not wasted
Jeremy Carroll: s/Jeremy/Jeff/
Zakim: alanr, you wanted to say fwiw, it's always harder to explain existential semantics in my experience
Ivan Herman: ack JeffP
Zakim: JeffP, you wanted to ask how to explain the difference to users
Alan Rutenberg: it's hard to explain existential issue with b-nodes...
Bijan Parsia: In the sparql working group, people like, Oracles Fred Zemke, clearly believed that bnodes were singular terms.

Ian Horrocks: some examples would be useful to explain people what this is about

ACTION: Jeff to lead effort on formulating some examples on b-nodes issues and their impact on users

Ian Horrocks: good there was lot of effort on this.. and also some new ideas, suggestions

ACTION: Jeremy to respond to boris's parsing idea by e-mail

Jeff Pan: bmotik, thanks for the pointer!


Ian Horrocks: no raised issues on agenda, no editorial either

Ian Horrocks: some to move on...

Ian Horrocks: ...syntax for allDisjoint... seemed simple, but complicated that if we have mapping for this, we should also have them for...

Peter Patel-Schneider: no need to go further in this discussion, syntax adapted to those few things that can be used a lot, not proposing extra syntax that do not require this

Peter Patel-Schneider: seems to be a reasonable resolution, unless people disagree

Jeremy Carroll: wants to ask what we have?
Bijan Parsia: As long as we have allDisjoint, I'm happy

Ian Horrocks: maybe we should resolve it?

Boris Motik: I didn't understand what Peter just said.

Jeremy Carroll: which special constructs do we mean?

Bijan Parsia: AllDijsoint, AllDifferent?
Peter Patel-Schneider: from owl 1.0, allDifferent, from owl 1.1 allDisjoint

Ian Horrocks: difIndividual, sameIndividual, etc.

Peter Patel-Schneider: ... that's all
Boris Motik: Peter, did you mean really making the syntax round-trippable, or do you think that we should just close issue as-is without mapping the syntax round-trippable?

Ian Horrocks: for allDisjoint there is aconstruct in semantics, there is nothing in mapping doc?

Michael Schneider: Question: do we already have "allDisjointProperties"? Is this useful?
Peter Patel-Schneider: yes, i think

Peter Patel-Schneider: all disjoints always had structural.abstract syntax...

Peter Patel-Schneider: all we want is special for allDifferent

Zakim: jeremy, you wanted to ask what we have?
Michael Schneider: not only roundtripping, but also triple bloat

Ian Horrocks: difficulty with proposed solution is that if there is only structural syntax, no corresponding serialization, we may get to round-trippable problem

Ian Horrocks: what we have now is what we had in owl 1.0

Jeremy Carroll: disjoint Obj Props is new here...

Michael Schneider: triple bloat at least for different or disjoint
Bijan Parsia: disjointClasses := 'DisjointClasses' '(' { annotation } description description { description } ')
Bijan Parsia: DisjointClasses(c1 ... cn)
Bijan Parsia: T(ci) owl:disjointWith T(cj) 1 Š i, j Š n, i € j

Peter Patel-Schneider: started with a fact that something that needs to be expressed... where it got complicated is when we brough round-tripping... should we be accountable f

Alan Ruttenberg: s/pfps/alanr
Jeremy Carroll: DifferentIndividuals(iID1 ... iIDn) T(iIDi) owl:differentFrom T(iIDj) 1 ? i, j ? n, i ? j

Boris Motik: what is peter's proposal? drop round-tripping, extend vocabulary? what is against extended vocabulary?

Jeremy Carroll: (I am supporting AllDisjoint and AllDifferent)
Boris Motik: +1 for n^2, but I believe that we need others as well
Alan Ruttenberg: alldifferent already existed

Peter Patel-Schneider: should we give up on round-tripping... to some extent, yes

Alan Ruttenberg: or take up roundtripping as a separate issue?
Bijan Parsia: I just want to make sure that n-ary Disjointclasses in functional syntax gets mapped to an analogous structure in rdf (an not n^2 disjointWiths) [Scribe assist by Bijan Parsia]
Boris Motik: On man...

Ian Horrocks: what's the problem of adding exactly that construct in mapping syntax? what is against it?

Boris Motik: Oh man....

Michael Schneider: another problem not mentioned: complete serialization needed until you know that you have all triples collected
Ian Horrocks: what's wrong with mapping all n-ary constructs [Scribe assist by Jeremy Carroll]
Michael Schneider: this would not be a problem, if all the classes would be in a single list

Ian Horrocks: people have diff opinions, there was a lot discussion on this

Bijan Parsia: I suggest an web based survey of the wg?

Alan Ruttenberg: isolate changes necessary to round-tripping...

Alan Ruttenberg: treat that separately and we can pay more attention to it

Ivan Herman: ack bmotik

Boris Motik: is round-tripping important? pls. vote....

Bijan Parsia: +1 but weakly
Doug Lenat: -1
Peter Patel-Schneider: round tripping is important, but not to the point of ...
Alan Ruttenberg: +0 think it is worthwhile, but should be considered against cost
Michael Smith: +1 round-tripping in general, but ok with just in OWL/XML
Doug Lenat: (that was clear from the way you phrased the question)
Peter Patel-Schneider: of course, we could round-trip into XML

Ian Horrocks: seems to be worthwhile investigating round-tripping = action?

Boris Motik: I can do this

Ian Horrocks: initial input to who is affected, what impact it has, ....

Boris Motik: I'll open a new issue, OK?
Alan Ruttenberg: or an action

ACTION: Boris to look at the round-tripping problem and collate initial material for/against it

Doug Lenat: good idea

Ian Horrocks: should we resolve Issue 2 and go for a new issue dedicated to round trippping?

Discussion on Issue 51 (quick)

Ian Horrocks: language name... some de-facto decisions

Ian Horrocks: called it owl 1.1.... any thoughts?

Peter Patel-Schneider: wanted to argue for 1.1.....

Bijan Parsia: wants to argue for OWL
Alan Ruttenberg: wants to agree with OWL1.1
Zakim: alanr, you wanted to agree with OWL1.1

Alan Ruttenberg: we chose 1.1 to continue as a product line

Alan Ruttenberg: is this still an issue? esp. only Jim seemed to have objected...

Jeremy Carroll: q+ to ask for W3C position?

Ian Horrocks: straw poll on what people think now?

Alan Ruttenberg: people asked whether this is still an issue.... people 'vote'

Jeff Pan: +1 OWL1.1
Doug Lenat: 0
Achille Fokoue: +1 OWL 1.1
Boris Motik: +1 to OWL 1.1
zwu2 (guest): +1 OWL 1.1
Bijan Parsia: -1 weakly
Michael Schneider: +1 OWL 1.1
Alan Ruttenberg: +1 weakly :)
Martin Dzbor: 0 (happier with OWL = continuity)
Jeremy Carroll: strong 0
Alan Ruttenberg: owl, weakly
Elisa Kendall: -1 due to significant syntax changes - which is one of Jim's points
Alan Ruttenberg: Elisa Kendall: Is there an alternative proposal?
Elisa Kendall: Not from me, but perhaps from Jim

Bijan Parsia: can live with 1.1... maybe just call it OWL... maybe hard to define how much needs to go into ".1"

Zakim: jeremy, you wanted to ask for W3C position?
Elisa Kendall: 2.0 would be better than 1.1 given syntax changes
Elisa Kendall: and I agree with Jeremy's analysis

Jeremy Carroll: this is perhaps a policy question... should we use "owl" as a technology, or is this a "separate" technology "owl1.1"? we should see w3c position

Bijan Parsia: Elisa, you realize that Pellet, using an OWL 1.1 parser, can pass all the OWL 1.0 test cases that it passed before?
Bijan Parsia: (and semantics)?
Elisa Kendall: yes, but that position is not true from an OMG perspective

Ian Horrocks: any other business?


Peter Patel-Schneider: which issues for next week?

Ian Horrocks: agenda for next week already available online

Ian Horrocks: agenda has quite some info in, so there is time to look at it and think about issues, discussion

Elisa Kendall: If you think about it from a graphical notation (i.e. UML profile) view, there are significant changes

Ian Horrocks: next week talking about punning, so pls. look at that

Alan Ruttenberg: suggests a check on issue times...

Bijan Parsia: read the primer and expanded syntax documents [Scribe assist by Peter Patel-Schneider]

Ian Horrocks: concluded.....

Last modified on 23 January 2008, at 15:15