Warning:
This wiki has been archived and is now read-only.
F2F2 Minutes
See F2F2 and F2F2 Agenda.
See also: IRC Log day 1, day 2
Contents
- 1 Opening Administrivia
- 2 Publication Schedule
- 3 Roadmap and design principles
- 4 Language Name (Issue 51)
- 5 OWL 2 Full Semantics Issues
- 6 Day 2 Admin
- 7 RDF Mapping Issues
- 8 Other Issues
- 9 Task Force Report: Imports and Versioning
- 10 Should we specify a Portable Location Override format?
- 11 Easy Keys
- Present
- Boris Motik, Peter Patel-Schneider, Bernardo Cuenca Grau, Rinke Hoekstra, Markus Krötzsch, Deborah McGuinness (day 1 only), Michael Schneider, Carsten Lutz, Achille Fokoue, Jie Bao, Zhe Wu, Evren Sirin, Michael Smith, Bijan Parsia, Uli Sattler, Jeremy Carroll, Evan Wallace, Sandro Hawke, Joanne Luciano, Ian Horrocks, Alan Ruttenberg
- Remote
- Elisa Kendall (for some parts of meeting)
- Regrets
- Observers
- Hanson Graves, Alex Tucker, Petr Kremen, Francis Gasse, Mike Grove, Dimitri Tsarkov, Thomas Schneider
- Chair
- Ian Horrocks, Alan Ruttenberg
- Scribe
- Jeremy Carroll, Michael Schneider, Michael Smith, Joanne Luciano, Evan Wallace, Bijan Parsia, Boris Motik
(No activity for 19 minutes)
(Scribe changed to Jeremy Carroll)
Opening Administrivia
RollCall
Boris, Peter, Bernardo, Rinke, Marcus, Deb (Thursday am only), Michael Schneider, Carston, Achille, Jie Bao, Evren, Mike Smith, Bijan, Uli, Jeremy, Evan, Sandro, Joanna, Ian, Alan, Zhe.
Elisa dialed in much of the time.
Observers
Hanson Graves (Lockheed Martin), Alex Tucker, Petr Kremen, Francis Gasse, Michael Grove, Dimitri (Univ of Manchester), Thomas Schneider, Kendall Clark, Matthew Horridge.
Local Arrangements
Kendall Clark has arranged dinner, sponsered by Clark&Parsia
22 for dinner
PROPOSED: Vote of thanks to Clark and Parsia
RESOLVED: thanks to Clark and Parsia
some people have not paid registration fees ... (scribe decides not to minute who!)
Agenda Review
Agenda review: Ian
Thurs am - discussion candidate FPWD docs
Thurs pm - roadmap and timeline
Thurs pm - 2nd session - OWL 1.1 Full
Fri am 1 - RDF mapping
some of these issues have been roadblocks
Fri am 2 other issues
Fri pm TF reports
Jeremy Carroll: 18.00 is a late end time
Ian Horrocks: who needs to leave before
Jie Bao 4pm
Ian Horrocks: will try to adjust agenda to finish by 4.30
Publication Schedule
Ian Horrocks - straw poll on each doc - are we ready to publish?
Alan Ruttenberg: expectations for publication
The goal is to get current work out for review. The docs do not have to be complete. It is common to have a mark "this is incomplete". The judgement to be made is: is it harmful to publish this? It is good to get things out as quick as possible.
For the straw poll assume the sort of editorial changes we might expect over the next couple of days, so we can publish tuesday?
Deborah McGuinness: what changes should we be expecting before we vote in straw poll
Sandro Hawke: vote expecting your small reasonable changes to have been made
STRAW POLL: Given some editorial changes that we might determine in this meeting, to be made in the next couple of days, would you agree to publish Primer on Apr 8?
lots of hands in favour
deborah no
several abstentions
STRAW POLL: Given some editorial changes that we might determine in this meeting, to be made in the next couple of days, would you agree to publish Fragments on Apr 8?
more lots in favour
none against
STRAW POLL: Given some editorial changes that we might determine in this meeting, to be made in the next couple of days, would you agree to publish XML Serialization on Apr 8?
lots in favour
none against
side comment about relax ng ... ignored
Ian Horrocks: we will go in reverse order of contention, start with fragments
Sandro Hawke: are we going to republish the three other docs?
Ian Horrocks: no - we discussed at telecon and decided against.
Publish OWL Profiles (Fragments)?
ACTION: Jeremy to RAISE issue on relationship between OWL-R non-entailments and OWL-Full entailments, and link to it from Fragments as EDITORIAL NOTE.
ACTION: Carsten to draft intro text for Fragments given high-level motivation, and add it into draft, as per his OWLED presentation
Achille Fokoue: range has been added to EL fragment
Achille Fokoue: as a result we don't have the right restrictions
Carsten Lutz: regarding EL we have a few glitches that lead to intractibility
Carsten Lutz: these are simple errors (editorial)
Boris Motik: there is a note in doc that these will change
Carsten Lutz: I could make these changes quickly
Achille Fokoue: we could also update references
Ian Horrocks: are we happy to carsten to make these changes?
Sandro Hawke: I would like someone else to review Carsten's changes
Ian Horrocks: there are others who can
ACTION: Carsten remove features that cause intractable in EL++
ACTION: Bijan to review Carsten's change of EL++
ACTION: Bernardo to review Carsten's change of EL++
(above discussion was regarding EL++ fragment)
Deborah McGuinness: we should mention OWL Lite
Jeremy Carroll: I would like to say "OWL Lite is deprecated", pfps agrees
Alan Ruttenberg: we could add editorial comment: "How we are going to document OWL Lite is not yet determined by the WG"
We all agreed on the following sentence ...
ACTION: Alan to add sentence "Although we don't specifically document OWL lite in this document, it is the intention of the WG that all OWL Lite ontologiies witll be OWL 1.1 DL ontologies" to Fragments
see Issue 107
ACTION: m_schnei to RAISE issue about how to refer to OWL Lite as a stable standard
The name of the document
Fragments-- peter, boris ...
Alan Ruttenberg: Ivan requested profile as W3C practice as recommended by QA group
Joanne Luciano: we should give justification for name in document
Joanne Luciano: I personally found the name 'fragments' confusing
proposal for profiles; seconded jjc
Ian Horrocks: will anyone speak against? Pfps holds nose.
Bijan Parsia: is OWL Full a profile?
Bijan Parsia: are we only using 'profile' for fragment
Bernardo Cuenca Grau: reads wikipedia defn
discussion of whether to raise this is an issue ....
Bernardo Cuenca Grau: can the word fragments be used in the intro
jeremy and ian: yes if in the context of logic
Alan Ruttenberg: the editorial change will be to leave one use of fragment in the intro
Alan Ruttenberg: and to use the word profile instead of fragment throughout
PROPOSED: we use the word "profile" instead of "fragment" throughout what has been called Fragments, with a reference to logic fragments, and explanation of the term "profiles"; and the title is ....@@@
Ian Horrocks: all docs are called OWL 1.1 Web Ontology Language: ...
PROPOSED: we use the word "profile" instead of "fragment" throughout what has been called Fragments, with a reference to logic fragments, and explanation of the term "profiles"; and the title for now is "[OWL 1.1 Web Ontology Language] Profiles"
Ian Horrocks: suggests just "Profiles" for the rest of the name
Jeremy Carroll: there was a nice adjective from Sandro
Sandro Hawke: but I've forgotten
PROPOSED: doc title is "profiles"
carsten is against other people in favour
PROPOSED: we use the word "profile" instead of "fragment" throughout what has been called Fragments, with a reference to logic fragments, and explanation of the term "profiles"; and the title for now is "[OWL 1.1 Web Ontology Language] Profiles"
RESOLVED: we use the word "profile" instead of "fragment" throughout what has been called Fragments, with a reference to logic fragments, and explanation of the term "profiles"; and the title for now is "[OWL 1.1 Web Ontology Language] Profiles"
(Bijan notes that a formal vote should be by organization, but this is not an issue for unopposed resolution)
ACTION: bernardo implement change of fragments -> profiles
Zhe Wu: would like to reorganize OWL-R section to get rules first
Ian Horrocks: do we need to do this for FPWD?
Zhe Wu: no, an editorial to do note is OK.
Alan Ruttenberg: a note should be added that the names of the profiles are not stable
ACTION: Alan to RAISE issue on picking good Names for Profiles AND link to this issue from Profiles document.
Sandro Hawke: actually reviewers comments have been in, but invisible by CSS
we could have a switch
PROPOSED: Let the TR actually keep the (yellow) wg-review-notes, with a switch to turn them on, default to off --- subject to W3C PubRules.
RESOLVED: Let the TR actually keep the (yellow) wg-review-notes, with a switch to turn them on, default to off --- subject to W3C PubRules.
(This resolution was amended the next day, to instead just link to the Wiki.)
PROPOSED: Publish Profiles (formerly known as Fragments) on or soon after Apr 8, given the changed agreed to in the past hour.
RESOLVED: Publish Profiles (formerly known as Fragments) on or soon after Apr 8, given the changed agreed to in the past hour.
Thanks and applause to authors
XML Serialization
Sandro Hawke: we need to have an issue about the namespace, an editorial note
ACTION: Bijan to RAISE issue on namespaces (if necessary) and link to it from document.
chairs will accept issues raised as a result of actions in this meeting
Bijan and jeremy: there is a separate issue about the OWL 1.1 namespace, this is different from the syntax namespace
Bernardo Cuenca Grau: there is a reference to 'fragments' in this doc
Alan Ruttenberg: won't the data-object property punning issue tomorrow impact these docs?
Jeremy Carroll: yes - but let's decide tomorrow
Bijan Parsia: fix typos when you see them
Rinke Hoekstra: The examples in section 2 are confusing
Rinke Hoekstra: they should either be exhaustive or non-existent
Evren Sirin: assuming functional syntax is normative are we expecting a mapping from XML syntax to functional syntax
Bijan Parsia: there is a couple of sentences that describe
Ian Horrocks: two issues: a) examples b) mapping should be explicit
Sandro Hawke: a complete example would be silly
Sandro Hawke: but a small example is helpful
Alan Ruttenberg: the example should be a repeat of some other example
Bijan Parsia: we could have pointer to the primer
Sandro Hawke: I would be happy with this
Bernardo Cuenca Grau: so the only doc with examples would be the primer
Bijan Parsia: I like that
lots of positive noises about this idea to examples
PROPOSED: kill example section replaced with pointers to primer
PROPOSED: We remove the examples section and just refer people to Primer, where they can use the XML tab to see examples.
Michael Schneider: the examples are not the same, it doesn't make sense to move it
Ian Horrocks: no the proposal is not to move the example but to delete it
Joanne Luciano: do the examples in the primer illustrate the right things?
Alan would like the link from serialization to primer to automagically come up in the right syntax
Alan claims this can be done in javascript
Alan Ruttenberg: the schema referred to in this doc needs to be accessible from this doc
Ian Horrocks: points out that Alan is out of order
PROPOSED: We remove the examples section and just refer people to Primer, where they can use the XML tab to see examples.
lots in favour
Achille Fokoue: I liked this example - relationship to mapping - hence I abstain
Achille Fokoue: also the namespace stuff, schemalocation etc, may be absent in primer
Bijan Parsia: but the primer may do these....
Joanne Luciano: I feel this is important
Jeremy Carroll: let's add a to-do
Ian Horrocks: let's put helloworld example in intro
Boris and Ian talk about mapping
Achille Fokoue: jeremy's proposal doesn't address mappings, but is otherwise OK
Ian Horrocks: mappings is next
PROPOSED: delete current example, add pointer to primer, and have Hello World in Intro
PROPOSED: delete current example, add pointer to primer, and have Hello World in Intro (eg bicycle subclassof vehicle)
RESOLVED: delete current example, add pointer to primer, and have Hello World in Intro (eg bicycle subclassof vehicle)
(No activity for 17 minutes)
ACTION: Sandro make sure that namespaces work right in the hello world example, and that the "separate document" link goes to the schema rather than the wiki page
(No activity for 10 minutes)
(Scribe changed to Michael Schneider)
Continuing on "Publication Schedule"
Alan Ruttenberg: next point is question about xml mapping
Bijan Parsia: suggests to add note "mapping should be enhanced"
PROPOSED: Publish "XML Serialization" on or soon after Apr 8, given the changes agreed to so far this meeting.
Jeremy Carroll: asks about GRDDL
Jeremy Carroll: we have already an issue on this
RESOLVED: Publish "XML Serialization" on or soon after Apr 8, given the changes agreed to so far this meeting.
Primer
Alan Ruttenberg: next point is primer
Alan Ruttenberg: what needs to be changed before vote to publish?
Deborah McGuinness: what plans exist for the primer, what has still to be done?
Bijan Parsia: explains list of things he wants to do (scribe did not get all the points)
discussion about whether deb's issues should be only marked as editorial
Zhe Wu: likes this whole document, but has problems with the database section
Zhe Wu: disagrees that database stuff is the most distinguishing point
Jie Bao: concern that primer is not ok for every one
Alan Ruttenberg: asks for suggestion for concrete words to put as editorial note
Bijan Parsia: hates database section because he thinks it is wrong
Bijan Parsia: still several months of work for the primer to do
Sandro Hawke: normally there is a sentence "please comment" at the beginning of a document, perhaps there should be more of these in the documents
ACTION: Bijan to draft the "humble" editor's note / SOTD request for comments for Primer
Alan Ruttenberg: option: remove the offending sentence from the database section?
Alan Ruttenberg: option2: remove complete database section?
straw poll on remove paragraph: 15 people
straw poll on remove whole database section: much less votes
Alan Ruttenberg: jie should put his points into document as note
ACTION: Bijan to add a from-community section for OWL 1.0 users, to Primer
Bijan Parsia: explains to deb that primer is intended for non-DL people
PROPOSED: Removing the paragraph from Primer beginning "It is this embracing of incompleteness..."
Peter Patel-Schneider: asks about why the whole paragraph should be removed instead of a single sentence
RESOLVED: Removing the paragraph from Primer beginning "It is this embracing of incompleteness..."
PROPOSED: Publish "Primer" on or soon after Apr 8, given the changes agreed to so far this meeting.
Deborah McGuinness: does someone has a list of intended changes?
ACTION: Deb to review primer+editorial changes after Bijan is done making them
ACTION: dlm to review primer+editorial changes after Bijan is done making them
ACTION: Deborah to review primer+editorial changes after Bijan is done making them
RESOLVED: Publish "Primer" on or soon after Apr 8, given the changes agreed to so far this meeting.
alanr congratulates authors and wg
(Scribe changed to Michael Smith)
Roadmap and design principles
Alan Ruttenberg: we will start with review of timeline
http://www.w3.org/2007/06/OWLCharter.html#deliverables
Review of Timeline
Alan Ruttenberg: in one view, there is much work to be done and that could prevent add'l items
...do we want to commit to this schedule and drop other things. lets open for discussion
Michael Schneider: we're making a lot of progress and shouldn't be constrained by a schedule set up front
Alan Ruttenberg: example of something that might not be done?
Michael Schneider: its too early to do so, that's my point
...our previous perception of timing has been incorrect
Jeremy Carroll: 6 months ago, rdf mapping was better than it is now, that suggests several more months are needed
Bijan Parsia: not all docs must march together
...I care about all features and have been expanding all the add'l proposals. I/Manchester is not ready to compromise on them.
Ian Horrocks: I agree with Bijan. Do we need everything to go to last call at the same time?
Peter Patel-Schneider: rdf mapping is not progressing b/c there are philosophical differences
... what are the philosophical differences? In 1.0 WG, once such issues were resolved, things went very fast
Sandro Hawke: to bijan, owl 1.2 is possible, this wg could continue for 10 years
...no promises, etc.
...this supports sticking to the current timeline, moving other issues to 1.2
Jeremy Carroll: in general, hp prefers longer gaps before versions. our target audience needs a perception of stability, and sandro's proposal undermines that
...suggest looking at charter to determine what must be at last call when
...I would personally vote against last call without rqmts doc
...it makes sense to do a cluster of docs together
Peter Patel-Schneider: HPs desire, of slowness, seems antithetical to Web and W3. i.e., we often hear of web years being 3-4 months
Jeremy Carroll: I think I would have difficulty selling sandro's proposal to colleagues
Ian Horrocks: to pfps on philosophical, I don't see such big philosophical differences
...on rqmts, yes we need such a doc, but note such rqmts have been gathered, just not pushed into a doc
Bijan Parsia: agree with ianh on rqmts being gathered
Alan Ruttenberg: on user facing docs, we're in good shape on what were the big issues
...a 1-2 pg quick start guide is part of this
...(scribe missed first of two things)
...I haven't heard other major problems in this area
...(review of charter wording and deliverables and current status)
...we're in good shape, but new features are outside and not r'qed by charter
...we need to be ready to slip schedule or drop these features
...anyone disagree on this characterization?
Jeremy Carroll: on test suite, we need something by last call
Alan Ruttenberg: I agree
Jeremy Carroll: you can't exit CR without test suite
Alan Ruttenberg: sandro noted slack in timeline, 3 months for dealing with feedback
Bijan Parsia: CR on timeline is generous b/c we have tracking implementations of the features
Jeremy Carroll: paperwork types will take some time
Sandro Hawke: if implementations are tracking, we don't need CR at all
Alan Ruttenberg: more feedback on features vs. time?
Achille Fokoue: keep on timeline, not add new features
Zhe Wu: agree with achille, note that vendors have to set a timeline
Bijan Parsia: not all the "slip" features weren't on the charter
Ian Horrocks: jeremy voiced hp concern on version numbers, how about IBM and Oracle
Achille Fokoue: I think the point is valid and think IBM might agree with HP
Zhe Wu: I agree
Joanne Luciano: provides example when sticking to timeline for sake of timeline has resulted in poor product
Sandro Hawke: if 1.2 option is off the table, schedule takes priority over features
Achille Fokoue: clarification, would 1.2 mean new charter, new WG
Sandro Hawke: no. this group would work in multiple phases
Achille Fokoue: that would be an issue, an ongoing commitment like that
Jeremy Carroll: its per feature
...nary i don't like
...easy keys sound good
...annotation spaces less clear, can be easily persuaded
Bijan Parsia: the new features are useful, this shouldn't be so absolute
Alan Ruttenberg: (scribe missed)
Michael Schneider: examples of impact
... if only semantics is broken it can be fixed, but rdf mapping is broken in a way that impacts owl-full, it can never be fixed
Rinke Hoekstra: some features are more important than others, that's obvious. we shouldn't confuse these things
...on 3 features, annotation is most important
Jeremy Carroll: hp is not expecting wg to meet timeline, I can't argue in favor of timeline
Achille Fokoue: I agree with rinke, not everything is equally important.
...slipping for 2-3 months is ok, longer commitment (e.g., 1.2 or another year) is a bigger issue, particularly if for non-essential features
...on 3 features, nary > annotation > easy keys
Zhe Wu: if 1.2 is on table, what's the timeline?
Alan Ruttenberg: charter schedule is last call at 10 months, 1.2 would be similar
Zhe Wu: delay 2-3 mos ok, another year not ok
Bijan Parsia: year not ok for me either
Zhe Wu: on 3 features, no preference
Markus Krötzsch: 2-3 mos ok, longer not, on 3 features annotation > easy >> nary
Alan Ruttenberg: first priority is what is on table now, willingness to extend up to ~4 months for new features
Backward Compatibility
statement on table: "Take an OWL DL 1.0 ontology O, serialize it to RDF and reverse map to an OWL DL 1.1 ontology O' in functional style syntax. O and O' have the same models as defined by their respective semantics."
Jeremy Carroll: observation - 1.0 is in terms of abstract syntax and semantics, 1.1 is not.
Ian Horrocks: the first order models are the same
Evan Wallace: this is only for DL, not full
Alan Ruttenberg: we have no proposal w.r.t. owl full
Jeremy Carroll: for full, everything true in 1.0 is true in 1.1
Michael Schneider: wait for my presentation
Bijan Parsia: can m_schnei inlcude a proposal in his presentation
Peter Patel-Schneider: what about the annotation exception
Alan Ruttenberg: status of annotations is not resolved, we want to avoid that now
Alan Ruttenberg: strawpoll on this defn of backwards compat for OWL DL
...see virtual unanimity
Bijan Parsia: I object
...I'd prefer to allow some small tweaks that would break formal but not de facto backwards
Alan Ruttenberg: noted
Jeremy Carroll: I abstained b/c I don't care, we know backwards compat when we see it. i.e., I agree with Bijan, we shouldn't prejudge some other issues
Issue 100 - Roundtripping DL through RDF Graphs
Ian Horrocks: (summarizes Issue 100) as should we be able to create OWL ontologies that we can't serialize as RDF
...we shouldn't have what alanr views as a bug in 1.0 (w.r.t. punning)
Bijan Parsia: objection, same as before, I don't see need to prejudge
Jeremy Carroll: I agree with Bijan and think this slightly knocks the previous WG
Alan Ruttenberg: no knocking involved
...I think it rises to a design principle b/c its relevant to users
Alan Ruttenberg: a proposal was made to me to handle punning for which I didn't have grounds to object to
Peter Patel-Schneider: previous wg had objectives, as different from, rqmts
Bijan Parsia: you can always object for the specific cases
Alan Ruttenberg: object to personalization. I'm speaking for a community, not trying to "win"
Jeremy Carroll: I agree with alan's design principle, agree with bijan on wg procedure
Sandro Hawke: perhaps we should record this as a use case
Ian Horrocks: there was a proposal this be a "design objective"
Alan Ruttenberg: what are our design principles, what are our rqmts
Uli Sattler: this design principle could conflict with some future case we don't know about and we should prohibit that case now
Jeremy Carroll: this should be in a document, not an issue
Sandro Hawke: having rqmts that conflict is normal
...this rqmt conflicting with a future one is ok
...I agree with jeremy on procedure
Bijan Parsia: apology to alan if taken personally
...I object to future debates being resolved by appeal to a design principle
...I believe your previous perception was incorrect and that you can object to specific issues w/o such a principle
...I think there is some issue with re-opening in the future b/c alan is a chair and has more significant power w.r.t issues
Ian Horrocks: adjourn for lunch
(No activity for 60 minutes)
(Scribe changed to Joanne Luciano)
Jeremy Carroll: discussing tech issues seems a good approach,
Alan Ruttenberg: round-tripping with RDF winds up with same set of models
Jeremy Carroll: add one or two sentences to current doc. if it turns out to be a bug then we fix it.
PROPOSE to close Issue 100 as resolved by adding round tripping text to the mapping document
PROPOSED: Close Issue 100 as resolved by adding roundtripping text to the RDF Mapping document.
PROPOSED: Close Issue 100 as resolved by adding roundtripping text to the RDF Mapping document.
+1
PROPOSED: Close Issue 100 as resolved by adding roundtripping text to the RDF Mapping document.
+9 (MITRE)
OOPS! +1 (MITRE)
RESOLVED: Close Issue 100 as resolved by adding roundtripping text to the RDF Mapping document.
Language Name (Issue 51)
PROPOSED: by Alan Call our product OWL 1.1
seconded by Bijan
Jeremy Carroll: from some previous WWC doc, a point release should be minor shift, this seems more like a major shift and suggests OWL 2.0
Bijan Parsia: Elisa suggests 2.0 because changes in structuarl syntax affects the UML form that perspective
Evan Wallace: agrees from tha tperspective
Sandro Hawke: Concern about backwards compability that may not hold for 2.0
Michael Schneider: personal feeling - most docs start with OWL 1.1, few but useful features
Achille Fokoue: Not much opinion on Name, IBM doesn't care, but concerned that will adding more will delay and prolong the process
Michael Schneider: no new stuff, what we have now is a big change
Zhe Wu: From Oracle, Oracle produces database, OWL 2.0 form marketing pt of view implies new features and supports it
Bijan Parsia: Keeping OMG in mind, regardless of naming issues, the fact that we're changing it from their perspective we need to listen and understand more
Bijan Parsia: Stability vs change, refers back to previous discussion about small vs big changes, and perceptions
Bijan Parsia: not a big change
Sandro Hawke: what would clinch this decision are there other major changes in mind for the future?
Bijan Parsia: Had sorted by his thoughts about the size of change, suggests going back and looking at what he thought then
Alan Ruttenberg: Agrees that changes API is big, though he's not done that
Matt Horridge: re: OWL API were needed anyway, i.e. for OWL 1.1 and could have put them in previous version
last coment from Horridge --correction, were needed for OWL 1.0 not 1.1
Michael Schneider: Can we try to compare with other W3C standards?
Bijan Parsia: we have different opinions of what's huge
Jeremy Carroll: owl 11 would call possible more typos than 12
Carsten Lutz: can we draw on history
Carsten Lutz: tends to think of this as 2.0
Rinke Hoekstra: bulk of people are those who download protege - doesn't matter to them // 2.0 might be a big disappointment because they've been waiting for these features for years
Bernardo Cuenca Grau: continues speculating
difference in opinion about speculation of user's response
8 people 1.1
votes for name 2.0 number is 6
Bijan Parsia: thinks 1.5 seems interesting
Elisa Kendall: suggests as compromise 1.55
who would object strongly as 1.1 --> 1
Bijan Parsia: pitch for 1.5, Elisa stated, reduce typo, indicated smaller change than 2.0, but larger than 1.5
Sandro Hawke: counter argumen - unprecedented - confusing
Markus Krötzsch: owl 1l.1 has been around, would confuse?
Ian Horrocks: same goes for 2.0
Uli Sattler: for user we called it 1.1
Jeremy Carroll: would need to consult with colleagues
Peter Patel-Schneider: if Elisa is objecting on OMG, Peter is objecting to her objection
votes for 1.5 approx 4
against 1.5 approx same
jjc would vote for with OMG reason
Sandro Hawke: we are using 1.1 now, can postpone
Ian, Alanr: don't want to put decision off
PROPOSED: The name is "OWL 2"
PROPOSED: The name is "OWL 2" (Issue 51)
11 votes for 2, one vote for 2.0
Deborah McGuinness: has to go, but doesn't care
PROPOSED: Resolve Issue 51 by saying the name is "OWL 2"
0 (MITRE)
RESOLVED: Resolve Issue 51 by saying the name is "OWL 2"
Boris Motik: change name now, will take 15 mins
No object to change doc name now
Boris Motik: changed his doc
Question about "short name"
Sandro Hawke: cross-references will be painful if we don't change name now
Bijan Parsia: do it when we re-publish /
Ian Horrocks: disagrees .... the sooner the better
Alan Ruttenberg: objects because we didn't publish that we would be making this change
Ian Horrocks: difference between publishing and updating
Sandro Hawke: software desitgned to be published all at once (a software issue). also, looks cumberson to reference "correctly"
Jeremy Carroll: these issues may justify breaking the normal process rules
Jeremy Carroll: state that they are being republished in order to substantiate the name change
Jeremy Carroll: can say we're not taking comments on these versions
Alan Ruttenberg: objects to publish doc that is about to be republished (alan correct if i got wrong)
Bijan Parsia: proposes making explict that it's same doc, only the name change and that subsequent will be the one to be reviewed
Boris Motik: syntax is already done
PROPOSED: REVERT, CHANGE, PUBLISH, REVERT BACK to roll back to last snap shot, change all 1.1 to 2, take new snapshot, status of doc is only name change
PROPOSED: Publish new versions of Syntax, Semantics, and Mapping-to-RDF with the ONLY change being the "1.1" -> "2" name change.
RESOLVED: Publish new versions of Syntax, Semantics, and Mapping-to-RDF with the ONLY change being the "1.1" -> "2" name change.
ACTION: Sandro to manage the previous documents 1.1->2 change
finished naming discussion
OWL 2 Full Semantics Issues
Slide: "OWL Full overview"
(Scribe changed to Evan Wallace)
But that doesn't mean that the interpretation is sensible
Slide: "OWL Full and OWL DL"
Michael Schneider: a class itself is itself an individual in the domain
State of OWL 1.1 Full Development
Michael Schneider: for 1.1 the semantics for Full should be conservative extension to OWL 1 Full semantics
Michael Schneider: Every DL entailment should also be a Full entailment in 1.1
Sandro Hawke: is it also true everything that is not entailed in Full should be not entailed in DL
Michael Schneider: see http://www.w3.org/2007/OWL/wiki/Full for current state of OWL 1.1 semantics proposal
Michael Schneider: about 1/2 the language features in this are ready for review
Slide: "Issues with OWL DL Compatibility"
Michael Schneider: OWL Full has infinite universe. This is simply shown
Michael Schneider: OWL Full always has entailments not existing in OWL DL
Michael Schneider: Have a feeling that OWL DL might have entailments not existing in OWL Full
Jeremy Carroll: Dave Turner did a study of the semantics of OWL 1.0 which the ref'd doc discusses
Slide: "Issues with OWL 1.0 Full"
Michael Schneider: Found bugs in semantics
Bug in sem for boolean axioms lead to OWL Full inconsistency
Michael Schneider: I will be writing this up in the Wiki page referenced earlier
Michael Schneider: Fixing this bug will lead to incompatibility with 1.0
Michael Schneider: RDFS has a collection of so called axiomatic conditions
Michael Schneider: PD* assumes certain of these semantic conditions that were not actually imposed on OWL Full
Slide: "Issues with OWL 1.1 Full"
Michael Schneider: Mapping for QCRs have a problem (which Peter has noted)
Michael Schneider: Every QCR will also be a normal CR in Full
Relevance is: Essentially QCRs unusable in Full because of this
Peter Patel-Schneider: All different is actually OK (This statement is incorrect.)
(Scribe changed to Boris Motik)
Alan Ruttenberg: Issue 69: punning is incompatible with OWL Full
Alan Ruttenberg: The main problem is with equivalence: if A sameas B, then A equivalent B in OWL Full but not in OWL DL
Alan Ruttenberg: What to do with these entailments?
Bijan Parsia & Alan Ruttenberg: We could say that this is not a ligal OWL DL entailment
Alan Ruttenberg: When we talk about semantic subsets, we talked about the status of the missing entailments
Alan Ruttenberg: There is a parallel with the fragments/profiles
Alan Ruttenberg: We should decide in general what our position is on such situations
Bijan Parsia: We should not have any additional entailments
Jeremy Carroll: We always think in terms of reasoner behavior
Jeremy Carroll: W3C talks about documents
Bijan Parsia: In OWL DL reasoning you care about the missing entailmens
Bijan Parsia: In OWL DL you care about "no" answers -- for example, when classifying an ontology
Alan Ruttenberg: Two points: (1) the analogy to DL-safe rules is not a good analogy because they require a new syntax, (2) Sandro brings up another option: we have always two modes
Sandro Hawke: This WG does not flag documents as being DL and Full; hence, we are not really specifying the meaning of documents
Bijan Parsia: Jeremy Carroll does not like punning because from the syntax we don't know which type of reasoning to use for a given ontology
Boris Motik: We might have an ontology property that would say which semantics it requires
Alan Ruttenberg: We have OWL Full, OWL DL, OWL-R; we should make a parallel between all these situations
Jeremy Carroll: Agrees with Alan Ruttenberg
Ian Horrocks: Clarifies that there is a problem with nonentailments in all these (sub)languages
Ian Horrocks: Is providing additional entailments optional or an error?
Peter Patel-Schneider: Does not agree with this analogy
Sandro Hawke: Does agree with the analogy
Bijan Parsia: Some people might not implement nominals, but missing entailments for nominals is an error
Peter Patel-Schneider: If you are not in OWL DL mode, you have to say you're not in the OWL DL mode
Peter Patel-Schneider: How far does the + go?
Peter Patel-Schneider: Can you go above OWL Full?
Bijan Parsia: Yes, you should be able to go above OWL Full.
Jeremy Carroll: If I introduce additional vocabulary and give it semantics, I see nothing wrong with allowing my reasoner to provide additional entailments
Bijan Parsia: We should not have a strict or nonstrict mode
Bijan Parsia: If people want to extend their tools, they are free to do so.
Bijan Parsia: Such extensions might fail the test suite, but who cares.
Ian Horrocks: Of course we can't stop implementors from implementing extensions
Ian Horrocks: In question is whether there should be a defined +
Ian Horrocks: Such + would have OWL Full as its top
Joanne Luciano: My first interpretation of + is any addition that someone might want to put on
Joanne Luciano: We should specify what we specify and not overlegislate
Alan Ruttenberg: Legislation means that we specify exactly what entailments we should specify
Alan Ruttenberg: This is a minimum
Alan Ruttenberg: Question to Zhe: are you comfortable about specifying OWL-R Full as "this is precisely the set of entailments that your reasoner should make"?
Zhe Wu: A strict mode is a good thing (it enhances compatibility)
Zhe Wu: Oracle has user-defined rule support
Zhe Wu: People might want to define uncles
Zhe Wu: Oracle wants to support the OWL-R subset in a strict mode, but it also wants to have the ability to extend this
Alan Ruttenberg: So a strict mode seems like a good idea
Ian Horrocks: I don't even thing it is necessary to say "you can do more"?
Ian Horrocks: If people want to do more, there is no way for us to prevent them from doing this
Sandro Hawke: But there is the test suite that says to the people what they can't do
Boris Motik: We might split the test suite into the positive and the negative part
Boris Motik: If people do additional stuff, they can then say what negative part they violated
Bijan Parsia: Vendors might distinguish the strict and "sensible" entailments
Jeremy Carroll: Whatever we decide, the DL tools will do what they want to do
Jeremy Carroll: Punning between classes and individuals is a "lost cause"
Jeremy Carroll: OWL-Full vendors will say whatever they wanted to do (sameAs implies equivalence)
Jeremy Carroll: This issue seems not worth discussing, because it will not make the difference to the world
Achille Fokoue: The reailty is that people will implement more and they will go beyond the strict mode
Ian Horrocks: I agree with Jeremy, but isn't that the argument to write the spec in exactly the way that the users want to do?
PROPOSED: We define our languages with an exact set of entailments
PROPOSED: We define our languages as some set of entailments. DL does not have certain entailments. OWL-R does not have certain entailments. Vendors can implemented other/related languages if they want.
Boris Motik: most people in favor, Jeremy Carroll has a problem with what the document means
Peter Patel-Schneider: I would prefer the situation where we had different document types for each kind of entailments
Peter Patel-Schneider: The WebOnt working group did not allow us to have this
Alan Ruttenberg: There is an uncertainty about what would happen in DL if sameAs should imply equivalence
Alan Ruttenberg: We should defer such questions to future WGs
PROPOSED: Resolve Issue 69 by specifying OWL DL and OWL Full by an exact set of entailments
PROPOSED: We define our languages as some set of entailments. DL does not have certain OWL Full entailments. OWL-R does not have certain OWL Full entailments. Vendors can implemented other/related languages if they want.
PROPOSED: Resolve Issue 69 saying that define our languages as some set of entailments. DL does not have certain OWL Full entailments. OWL-R does not have certain OWL Full entailments. Vendors can implemented other/related languages if they want.
PROPOSED: DL does not have certain OWL Full entailments. OWL-R does not have certain OWL Full entailments. Vendors can implement other/related languages if they want.
RESOLVED: DL does not have certain OWL Full entailments. OWL-R does not have certain OWL Full entailments. Vendors can implement other/related languages if they want.
Bijan Parsia: There is no way to indicate the semantic intent. We could introduce MIME types
Alan Ruttenberg: Not on the agenta, bijan should raise an issue
Alan Ruttenberg: Issue 12 is closed
Alan Ruttenberg: Issue 67, Issue 81: Reification issues
Alan Ruttenberg: Jeremy split this into two cases: (1) the use of reification for annotations, and (2) the use of reification for negative property assertions
Alan Ruttenberg: I'd like to split these two issues
Alan Ruttenberg: Issue 81 is different from Issue 67 in the sente that annotations might not have semantics at all, so they would not affect the formal meaning of an ontology
Alan Ruttenberg: Question to jeremy and m_schneider: could we say that Issue 67 is not a problem and focus on Issue 81
Michael Schneider: The use of reification is opposed by the community, so this is why I would not use it
Michael Schneider: Do we want to use RDF reification.
Michael Schneider: It is not a technical or a semantic problem; this is a nicety issue
Michael Schneider: People just don't like reification
Bijan Parsia: There are lots of alternative encodings
Bijan Parsia: Boris was in favor of reification because reification was designed for this purpose
Boris Motik: We need to encode more than binary predicates, so we'll need to reify them
Boris Motik: Reification is necessary and people are doing it already in general
Michael Schneider: I don't see some other opporunity for encoding negative assertions
Alan Ruttenberg: Achille and Zhe, do you care about this?
Achille Fokoue: I don't care
Zhe Wu: People hate reification
Zhe Wu: Reification requires joins so I'd like to avoid it
Alan Ruttenberg: We could reolve this issue by saying "we can try something else"
Jeremy Carroll: We are then not resolving, but just postponing the issue
Jeremy Carroll: What is the problem with a complemented hasValue assertion?
Bijan Parsia: This is bad because you can use negative assertions without nominals
Bijan Parsia: Using a nominal for just a property assertion makes it difficult to say what is allowed in which fragment
Michael Schneider: Likes shadow vocabulary
Jeremy Carroll: Dislikes shadow vocabulary
Alan Ruttenberg: Solving this technical problem in this room is likely not to work
Alan Ruttenberg: I propose that we record that we don't like this issue and that we postpone the resolution until later
Bijan Parsia: Have we learnt that people really dislike reification?
Jeremy Carroll & Sandro Hawke: Would vote -0 on using reification
ACTION: Bijan to come up with proposals for Issue 67 and Issue 81.
Jeremy Carroll: HP has discovered that special support for reification is costly and we'll drop it in future
Alan Ruttenberg: Issue 90, Issue 91: Related to backwards compatibility
Michael Schneider: I have a proposal for addressing this
Michael Schneider: I propose to have deprecations as semantic-free annotations
Michael Schneider: I propose to keep OWL-Full as is
Michael Schneider: Do not deprecate Deprecation
Peter Patel-Schneider: Let me say what Michael's proposal should be
Peter Patel-Schneider: There should not be deprecated classes and properties in OWL 2 DL
Peter Patel-Schneider: owl:DeprecatedClass and owl:DeprecatedProperty should be the same as owl:Class and owl:Property
Michael Schneider: In OWL 1 DL, the following was the case:
Michael Schneider: There were OWL 1 DL deprecated classes and properties
Michael Schneider: There was a special "deprecated" flag in the abstract syntax
Michael Schneider: There was a special trick for handing the "deprecated" flag in the AS
Michael Schneider: This flag was handled in the semantics using an artificial rdf:type property
Michael Schneider: This was confusing
Michael Schneider: From the semantic point of view: there no mapping of an rdf:type property from OWL/RDF into AS
Michael Schneider: In OWL 1, annotations do have a semantics, so all this mattered
Peter Patel-Schneider: This was done in order to turn a one-place thing into a two-place thing
Michael Schneider: My proposal is to map owl:DeprecatedClass and owl:DeprecatedProperty into annotations in the structural spec
Ian Horrocks: Do you care about round-tripping RDF -> FS -> RDF?
PROPOSED: Is it okay to read in an OWL 1 ontology (with deprecated classes) into an OWL 2 system -- then you write it out again, is it still OWL 1
Ian Horrocks: You take an OWL 1 ontology with deprecated classes, you read it into an OWL 2 system, you write it out. Do we care about whether the deprecated triples are the same?
Michael Schneider: objects to this
Michael Schneider: If we have an RDF graph with some deprecation statements.
Michael Schneider: I put such an ontology into an OWL Full reasoner
Michael Schneider: I put it into an OWL DL system, and serialize it again
Michael Schneider: What I get in the end is something that is quite different from what I started with
Bijan Parsia: What is the general cost of existing ontologies?
Bijan Parsia: If this is a corner case in practice, this might not be worth investigating
Achille Fokoue: I agree with m_schneider that this might be a problem, but we might put the compatibility bar too high
Achille Fokoue: You can have the ability in your tool to preserve depecations
Achille Fokoue: I don't see the absolute need with perfect round-tripping
Rinke Hoekstra: The functional-syntax is suited for OWL DL
Rinke Hoekstra: I cannot really imagine anyone loading an OWL Full ontology in an OWL DL tool
Rinke Hoekstra: Deprecation is a tool issue
Michael Schneider: I create an OWL DL ontology with Protege
Michael Schneider: I want to use an OWL Full reasoner to get additional entailments
Michael Schneider: To me this is a valid use case
Jeremy Carroll: The issue is whether we want to have deprecation
Alan Ruttenberg: I'm taking it as given that we are not getting rid of it
Jeremy Carroll: My point, Alan Ruttenberg
Jeremy Carroll: There clearly is a use for deprecation
Peter Patel-Schneider: I do not believe that the WG has made any decision about deprecating Deprecation
Alan Ruttenberg: I don't think it would be a good decision to deprecate deprecations because this might give us problems
Jeremy Carroll: If we are not going to deprecate deprecations, then let's just do a bit of hackery to make it work
ACTION: bmotik2 to Propose a way to reintroduce annotations into the structural specification and to provide RDF mappings
PROPOSED: Hack the RDF mapping and functional syntax as necessary to allow DeprecatedClass and DeprecatedProperty to work as in OWL 1
PROPOSED: Close Issue 90, resolved. We will hack the RDF mapping and functional syntax as necessary to allow DeprecatedClass and DeprecatedProperty to work as in OWL 1
RESOLVED: Close Issue 90, resolved. We will hack the RDF mapping and functional syntax as necessary to allow DeprecatedClass and DeprecatedProperty to work as in OWL 1
Boris Motik: No objectors, resolved unanimously
Alan Ruttenberg: Issue 91: Spec lacks ontology properties
Jeremy Carroll: Add a note that these ontology properties should be used only on ontologies
PROPOSED: Close Issue 91, with text saying not to do this (ontology properties should only be used to relate ontologies -- if you go against our advice, you're on your own.
PROPOSED: Reolsve Issue 91 by adding a note in the structural spec by saying that ontology properties should not be used elsewhere as annotations
RESOLVED: Close Issue 91, with text saying not to do this (ontology properties should only be used to relate ontologies -- if you go against our advice, you're on your own.
Boris Motik: Here is the implementation of Issue 91: http://www.w3.org/2007/OWL/wiki/index.php?title=Syntax&diff=5375&oldid=5331
Day 2 Admin
(Scribe changed to Bijan Parsia)
RDF Mapping Issues
Ian Horrocks: First up is fixing a bunch of issues by eliminating data/object property punning. Boris has a lil presentation on a proposal.
Boris Motik: Two basic roots to many issues in the mapping: 1) object/data/annotation punning and 2) typing occurances of terms (2 gets driven by 1)
Alan Ruttenberg: But we require typing in OWL 1.0?
Boris Motik: But in 1.0 it's not quite worked out.
[And in 1.0 you can get away with *global* typing whereas with punning you need *local* typing --- bijan]
Jeremy Carroll: Do we need typing for annotations?
Boris Motik: yes; and there is object/data punning in annotation properties (even in 1.0)
Boris Motik: Propsoal: disallow property punning and require a type for every (property) URI
Boris Motik: Changes to the specs. Use declarations in the struc spec/functional spec (but map them to type triples) (see slide 3 for details)
Alan Ruttenberg: Do we type ontology properties as well?
Boris Motik: With the current ontology properties there's no need since we have a list of them.
Jeremy Carroll: And that was deliberate...ontology properties were a closed set so you can just look for them.
Michael Schneider: What about typing vocabulary?
Boris Motik: I'm talking about at the level of the structural spec so no type triples
Michael Schneider: I mean the typing in the quantifers, e.g., objectSomeValuesFrom
Boris Motik: getting to it
Jeremy Carroll: What about typing inference?
Boris Motik: I deal with that. But i think at the structural spec level we should require declaration. But what your are talking about is "repair" and we should allow that. But the tool should generate the type triples internally.
Bijan Parsia: are we specing the repair rules?
Ian Horrocks: (as chair) We have a later agenda item on it.
Boris Motik: UML diagrams stay the same. We augment the grammar for functional style syntax with some annotations indicating the required global type.
...this means that the diagrams match the grammar, but we don't have in the explicit syntax any typed terms but we do have productions that indicate what the type of the construct is (e.g., no typed terminals, but the non-terminals can be typed so there is not a large change from the current spec or apis)
Discussion about whether tools should add types in all files where there are missing types. A lot of discussion about whether to make this recommondation. This behavior is highly undesired for some people.
Discussion is actually about whether to recommende putting htings at the tope of the store.
Alan Ruttenberg: Suggests adding more context making clear that devianting from this advice is ok, but has costs.
Alan Ruttenberg: Declare before use still suggests a per document bias.
Sandro Hawke: This falls into the "if you put triples in a particular order you can do well"
Bijan Parsia: But we could incorporate this in the "nice serialization" stuff that I've suggested we offer earlier.
Boris Motik: Changes to RDF mapping; this fixes tons of problems, e.g., non-mon gone, remove duplicate vocabualry etc.
Boris Motik: We should make clear that repair isn't part of the spec....type validation is based on the explicit set of triples
Boris Motik: "declaredAs" will go away in RDF
Boris Motik: Given cyclic imports and typing triples occuring anyway, the parsing algorithm has to be two pass.
s/boirs/boris/
Jeremy Carroll: While we can express this, we shouldn't say it is *required*
Boris Motik: yes, but I think *speccing* it as two pass will be clearer...obvious people can optimize better.
Alan Ruttenberg: This is another notes to implementors. We should have an additional section
Boris Motik: importing files of different syntaxes?
...But now we can formulate things at the object model so mixed imports (and typing) becomes clean.
Boris Motik: Changes to XML Syntax: Drop typed quantifiers as in the functional syntax. Regularizes all the syntaxes and makes the parsing (at a high level) exactly the same.
Jeremy Carroll: secondes the proposal
Michael Schneider: Can we defer some other issues?
Generally people wanted to do things on a case by case basis.
Sandro Hawke: We can make decisions and if we find problems later then we can reopen the decision.
Issue 17
Ian Horrocks: This is a non-issue if we accept the boris proposal.
...Thus this issue is resolved by this proposal.
Jeremy Carroll: One use case from the "Full/RDF" domain is dc:creator, but I don't believe it is address by punning so I don't think we harm that use case *more*.
Peter Patel-Schneider: I'd like to mark that we don't agree with the lack of use cases.
Ian Horrocks: So we'll say that we technically don't know how to do it so we closed it.
Evan Wallace: about boris's proposal: The only place the proliferation of typed vocabulary occurs is in the struc spec?
Boris Motik: Yes.
Ian Horrocks: But only in non-terminals. Terminals are all type free.
Bijan Parsia: But that could impact the OMG UML mapping
boris's proposal: http://www.w3.org/mid/000001c89659$6d8508f0$2a12220a@wolf
PROPOSED: Close Issue 17 as resolved, saying we forbid any property punning, as per Boris' proposal (http://www.w3.org/mid/000001c89659$6d8508f0$2a12220a@wolf) with a note that the reason is that technically we don't know how to do it.
+1
RESOLVED: Close Issue 17 as resolved, saying we forbid any property punning, as per Boris' proposal (http://www.w3.org/mid/000001c89659$6d8508f0$2a12220a@wolf) with a note that the reason is that technically we don't know how to do it. NOTE that Boris doesn't mention AnnotationProperties here, but they are understood as being parallel to DataProperties and ObjectProperties
Issue 18
Jeremy Carroll: I'm not sure who did Issue 18 though my name is on it.
...So I withdraw it.
Issue 65
Ian Horrocks: The new proposal addresses this explicitly.
Jeremy Carroll: I'm happy as long as after the edits the terms are actually fully reduced.
Ian Horrocks: We can always revisit if things turn out unexpectedly.
Jeremy Carroll: I believe the proposal addresses this, but obviously I need to check.
Issue 89 and Issue 19
Ian Horrocks: Proposal fixes this.
Michael Schneider: There is an issue. It's not clear but in OWL 1 some type triples are entailments and now if they have no semantics we have a backward compatibility issue.
Boris Motik: it's not about entailment.
Jeremy Carroll: The entailment still holds.
Alan Ruttenberg: There was some old wording saying that declarations don't have semantics.
Boris Motik: and it *doesn't* have semantics.
Alan Ruttenberg: Simple proposal: let's remove the wording (about no semantics) but leave things as it is
Markus Krötzsch: You cannot ask that something a subclass of thing you have to priorly said that it's a class, so in some sense it changes the semantics but not in the ordinary sense we mean when dropping an axiom.
Peter Patel-Schneider: Where do we *say* in the document that declarations have no semantics.
...No where.
alan (strikes back): Finds some text that seems to be problematic.
pfps and jjc: that seems false
Ian Horrocks: Ok, that's a separate issue and seems largely editorial.
Evan Wallace: How do we handle this editorial/whatever issue.
PROPOSED: Close Issue 65, Issue 68, Issue 89, and Issue 19 as resolved, as per Boris' proposal (http://www.w3.org/mid/000001c89659$6d8508f0$2a12220a@wolf), amended to include AnnotationProperties in parallel to DataProperties and ObjectProperties.
Michael Schneider: What is the status of the semantics of declarations? I
...'m still confused.
PROPOSED: Close Issue 65, Issue 68, Issue 89, and Issue 19 as resolved, as per Boris' proposal (http://www.w3.org/mid/000001c89659$6d8508f0$2a12220a@wolf), amended to include AnnotationProperties in parallel to DataProperties and ObjectProperties.
+1 (Manchester)
RESOLVED: Close Issue 65, Issue 68, Issue 89, and Issue 19 as resolved, as per Boris' proposal (http://www.w3.org/mid/000001c89659$6d8508f0$2a12220a@wolf), amended to include AnnotationProperties in parallel to DataProperties and ObjectProperties.
Issue 66 & Issue 94
Ian Horrocks: In the RDF Mapping boris added the following text: "More precisely, let O be any OWL 2 DL ontology in functional-style syntax, let RDF(O) the set of RDF triples obtained by transforming O into RDF triples as specified in Section 2, and let O' be the OWL 2 DL ontology in functional-style syntax obtained by applying the reverse-transformation from Section 3 to RDF(O); then, O and O' are logically equivalent (i.e., they have exactly the same set of models)."
Ian Horrocks: This resolves the issue.
Jeremy Carroll: I accept it resolves the issue, but it's editorially nasty.
Sandro Hawke: Let me understand: Roundtripping gives you the same models, but not necessarily the same syntactic mapping. It would be nice to mention this.
PROPOSED: Resolve Issue 66 by adding to the RDF Mapping the following text: "More precisely, let O be any OWL 2 DL ontology in functional-style syntax, let RDF(O) the set of RDF triples obtained by transforming O into RDF triples as specified in Section 2, and let O' be the OWL 2 DL ontology in functional-style syntax obtained by applying the reverse-transformation from Section 3 to RDF(O); then, O and O' are logically equivalent (i.e., they have exactly the same set of models)."
Achille Fokoue: We've asserted this, but what's the status of proving it? Do we require a formal proof?
Ian Horrocks: Formal proofs for mapping seem a bit different than formal proofs for semantics etc.
Jeremy Carroll: This resolution resolves things by making any falsity in the roundtripping a bug not a feature. How we detect and fix such bugs is a different issues.
Ian Horrocks: The semantics equivalence claim in the profiles document has a different status
+1 (Manchester)
Issue 86
Ian Horrocks: MikeS has a solution to mapping inverse property expressions: <http://lists.w3.org/Archives/Public/public-owl-wg/2008Mar/0269.html>
Michael Smith: Instead of trying to use a bnode in property position, reverse the arguments.
Michael Schneider: I have a solution and it's a more general problem. Inverse expressions are a symptom.
...The problem is more general...can we tackle the more general problem
Boris Motik: we should fix the concrete case.
Jeremy Carroll: One problem with hasValue restrictions is that it uses a very expressive construct for a less expressive bit.
Ian Horrocks: And hits roundtripping hard.
Boris Motik: It's a simple simple solution that fits in with the rdf etc. etc.
Michael Schneider: My problem is that I dismissed it so, I didn't understand it.
Markus Krötzsch: If we encounter new problems, we'll have to revisit the hack anyway.
Uli Sattler: It's not a hack...it's a standard technique, used in rewriting of conjunctive query, etc.
(No activity for 35 minutes)
(Scribe changed to Achille Fokoue)
PROPOSED: resolve Issue 86 as proposed in http://lists.w3.org/Archives/Public/public-owl-wg/2008Mar/0269.html; it is believed that this is the only place that this problem arises.
PROPOSED: resolve Issue 86 as per proposal 2 in http://lists.w3.org/Archives/Public/public-owl-wg/2008Mar/0269.html; it is believed that this is the only place that this problem arises.
+1 (IBM)
RESOLVED: resolve Issue 86 as per proposal 2 in http://lists.w3.org/Archives/Public/public-owl-wg/2008Mar/0269.html; it is believed that this is the only place that this problem arises.
Issue 94: Issues surrounding roundtripping
Alan Ruttenberg: let's reject it
Bijan Parsia: it might be nice to regularize it
Alan Ruttenberg: do we want a resolution
Bijan Parsia: if we reject it I will hjave another one with disjoint
Michael Schneider: n-ary construct map to a lot of binary statement in rdf
... this is not very nice, It will address the problem of annotating n-ary constructs
Jeremy Carroll: we are not solving the annotation issues in this metting
Jeremy Carroll: we do not rule out them for now
Ian Horrocks: add it for disjointProperty and close this issue
PROPOSED: Resolve Issue 94, introducing disjointProperties (and note that disjointClasses is already in OWL2), handled like allDifferentFrom was in OWL 1
+1 (IBM)
Peter Patel-Schneider: we are adding more vocabulary
RESOLVED: Resolve Issue 94, introducing disjointProperties (and note that disjointClasses is already in OWL2), handled like allDifferentFrom was in OWL 1
Issue 96 OWL-1.1 vocabulary naming in RDF mapping is not consistent
Ian Horrocks: inconsistency in the vocabulary naming
Michael Schneider: disjointObjectProperties instead of disjointObjectPropertyWith
Alan Ruttenberg: disjointObjectPropertiesWith is not good english
Alan Ruttenberg: let's change then all to make it better english
... all = (disjointClasses and disjointProperties)
Evren Sirin: disjointProperties as we have equivalentProperties
Evan Wallace: disjointProperty as we have equivalentProperty
Michael Schneider: onely one case with singular
jjc: a note to signal a potential alternative design
Jeremy Carroll: get rid of the binary case
PROPOSED: we do not have special vocabulary for pair-of-disjoint properties, but we include an editor's note asking for feedback from OWL Full community about whether they want PropertyDisjointWith or whatever.
Michael Schneider: we have case where we have binary only, n-ary and binary, and n-ary only
Bijan Parsia: this is not a major issue (i.e. the lack of regularity in the language)
Michael Schneider: in this case I would like to reject the issue
PROPOSED: resolve Issue 96, using owl:propertyDisjointWith for the binary case of disjoint properties
0 (IBM)
0 (IBM)
RESOLVED: resolve Issue 96, using owl:propertyDisjointWith for the binary case of disjoint properties
Jeremy Carroll: i will report to hp that many of the key issues have been addressed
Other Issues
Issue 3 & Issue 46 anonymous individuals / Unnamed Individual Restrictions
Boris Motik: allow bnodes in the structural spec
Boris Motik: interpret them as anonymous individuals
Boris Motik: mandate that the assertion are tree like to guarantee decidability
Jeremy Carroll: the experience is that owl implementaters have interpreted them as skolem
Bijan Parsia: by this change we will make all owl tools non-conformant
Bijan Parsia: i do not see it as a good idea
Bijan Parsia: i would prefer not having them at all
Evren Sirin: + 1 for bijan
.. but I do not think it makes all tools non-conformant
... I am talking about OWL 1.0
Jeremy Carroll: I agree with evren. OWL 1.0 test cases are about consistency check
ACTION: bmotik2 to Modify entire spec according to the proposal from http://lists.w3.org/Archives/Public/public-owl-wg/2008Apr/0018.html
Bijan Parsia: I would liek to break the backward compatibility in the spec
Michael Schneider: cyclic property assertions ?
Ian Horrocks: it would be illegal as not being tree shape
Ian Horrocks: if we resolve this according to boris's proposal, it is up to bijan to introduce the skolem semantics
Jeremy Carroll: three possibilities: 1) no anonymous individuals, 2) individuals as skolem
3) as per boris's proposal
PROPOSED: (1) no anon individuals (2) anon indivs as per Boris (3) anon indiv with skolem semantics
PROPOSED: OPTION-1
-0
PROPOSED: OPTION-2: (2) anon indivs as per Boris
0
PROPOSED: OPTION-3: (3) anon indiv with skolem semantics
+0.25
Michael Schneider: i am interested in an example where the existential semantics is used
Bijan Parsia: it is never used
Michael Schneider: the statement was for DL
Michael Schneider: could jeremy provide some evidence of this use in DL ?
Sandro Hawke: we want to add in the draft that we understand that it is non consensual
Evren Sirin: how about give the skolem semantics for DL and existential for Full
Ian Horrocks: let's not discuss evren's proposal now
Bijan Parsia: i will write a proposal so that we can use it as the starting point for further discussion
ACTION: Bijan to put consolidated list of OWL visible differences between bnode semantics as existential versus skolem
PROPOSED: Resolve Issue 46, accepting Boris's proposal (http://lists.w3.org/Archives/Public/public-owl-wg/2008Mar/0008.html) only in terms of the syntax of bnodes, and open a new issue on the semantics of bnodes, including editorial note in owl2-syntax about semantics being still open.
PROPOSED: Resolve Issue 3 and Issue 46, accepting Boris's proposal (http://lists.w3.org/Archives/Public/public-owl-wg/2008Mar/0008.html) only in terms of the syntax of bnodes, and open a new issue on the semantics of bnodes, including editorial note in owl2-syntax about semantics being still open.
+1 (IBM)
RESOLVED: Resolve Issue 3 and Issue 46, accepting Boris's proposal (http://lists.w3.org/Archives/Public/public-owl-wg/2008Mar/0008.html) only in terms of the syntax of bnodes, and open a new issue on the semantics of bnodes, including editorial note in owl2-syntax about semantics being still open.
ACTION: bmotik2 to Update the structural spec to add anonymous individuals; no mention about semantics so far
Issue 16 entity annotations
Ian Horrocks: we have a proposal from boris
Boris Motik: Only annotations . The target of annotation will be either entity or annotation
Bijan Parsia: i request it to be postponed because I need to think about it more in the context of my annotation proposal
Peter Patel-Schneider: another proposal (much simpler) from me
Peter Patel-Schneider: what is the status of entity annotation?
Peter Patel-Schneider: I would vote to reject the issue because there is nothing wrong
Jeremy Carroll: the issue is about metaannotation
Jeremy Carroll: the ability to annotate the annotation
Peter Patel-Schneider: my proposal does that
Bijan Parsia: this is an important issue for debra
Achille Fokoue: this is also an important issue for IBM
Ian Horrocks: we should carry that discussion on emails
ACTION: jjc to drive this issue forward to resolution
Issue 72 Annotation Semantics
Ian Horrocks: the current spec gives no semantics to annotation
and it is not 100% compatible with OWL 1
Alan Ruttenberg: the case I am aware of is if you have 2 individuals that are same as
then annotations in one is also annotations on the other
Michael Schneider: I have also found a bug in the semantics
Michael Schneider: I will send an email to the WG because I do not remember
... the details
Alan Ruttenberg: by which mechanism the annotation remains with the annotated object
Jeremy Carroll: this example with sameAs. the annotation is about the syntax (i.e the uri)
Jeremy Carroll: annotations are always about the syntax not the semantics
Bijan Parsia: I agree with jjc for the most part
Bijan Parsia: tools can address this issue by presentating same individual together
for example
Bijan Parsia: it should be handled at the level of tools
Bernardo Cuenca Grau: are we talking about a backward compatibility issues or are we talking about annotations in general
Bernardo Cuenca Grau: we should focus on backward compatibility only
Evren Sirin: second jeremy's point: annotations are on the syntax
Bijan Parsia: I agree with Markus
MarkusK, thanks for your script assist
s/script/scribe
Ian Horrocks: it seems to me that we should accept that the semantic is not backward compatible
Alan Ruttenberg: my concern is that the semantics of annoation are not understood
alan; my experience tells me that tools do not have a standard way to deal with annotations
Ian Horrocks: I am saying that the resolution that they do not have a semantics leads to a backward compatibility issue
Bijan Parsia: two things:
.. 1) what are the semantics?
... 2) the documentation is not perfect
... we should do a better jobs on documentating annotations this time around
Alan Ruttenberg: we are not committed to backward compatibity on annotation
Alan Ruttenberg: we will clarify its semantics even with the risk of breaking backward compatibity
Sandro Hawke: owl 2 is a superset of owl1 with some bugs fixed
... maybe I should add that we may also break compatibility on annotations
Alan Ruttenberg: my concern is that by saying that it has no semantics, the typical tool may simply ignore them
Peter Patel-Schneider: what does protege do?
Matthew Horridge: protege does not throw them away
Evren Sirin: 1) OWL 1 has semantics for annotation but tools still ignore them (for example reasoners)
Evren Sirin: it will be fixed soon in pellet
PROPOSED: we are not committed to backward compatibility with respect to annotations
PROPOSED: we are not committed to backward compatibility with respect to annotation semantics
PROPOSED: Close Issue 72 saying we are not committed to backward compatibility with respect to annotation semantics, given that the WG will attempt to improve annotation support in OWL 2
+1 (IBM)
RESOLVED: Close Issue 72 saying we are not committed to backward compatibility with respect to annotation semantics, given that the WG will attempt to improve annotation support in OWL 2
Task Force Report: Imports and Versioning
Alan Ruttenberg: assumptions: 1) ontologies will be versioned
Alan Ruttenberg: 2) terms may not be versioned , 3) different versions will coexist at different locations
alan presentation will be sent to the WG mailing list
s/ alan presentation / alan's presentation
Alan Ruttenberg: after the import closure is done, all the version requirements are checked
Alan Ruttenberg: in case of violations, tools can request users intervention
Jeremy Carroll: this is a generic pb
Jeremy Carroll: it is not owl specific.
s/pb/problem
Alan Ruttenberg: there is an implication that OWL addresses this issue
Alan Ruttenberg: an external mapping file specifies the location of the OWLontologies
Alan Ruttenberg: this is not a report from the task force
Alan Ruttenberg: it is just a proposal from me
alan's proposal is at : http://lists.w3.org/Archives/Public/public-owl-wg/2008Apr/0016.html
(No activity for 49 minutes)
(No activity for 10 minutes)
PROPOSED: We should incorportate peter's "basic idea"
PROPOSED: (1) don't do anything about versioning, (2) minimal (Peter's) versioning, (3) substantial (Alan's) versioning
Should we specify a Portable Location Override format?
PROPOSED: Resolve Issue 21, to say we're importing by location and that, modulo overrides, modulo versioning, the ontology at U SHOULD have name U.
PROPOSED: Resolve Issue 21, to say we're importing by location and that, modulo overrides, modulo versioning, the ontology at U SHOULD have name U.
PROPOSED: Resolve Issue 21, to say we're importing by location and that, modulo versioning, the ontology imported from U SHOULD have name U. There may be some kind of override of location, but not the name.
PROPOSED: Resolve Issue 21, to say that import is fundamentally by location, and that what you retreive from that location should give its name as that import-location. There may be overrides along the way to retreiving that content, but the import-text and the final-name text SHOULD be the same. All of this may be changed to accomodate versioning..
PROPOSED: Resolve Issue 21, to say we're importing by location and that, modulo versioning, the ontology imported from U SHOULD have name U. There may be some kind of override of location, but not the name.
(No activity for 23 minutes)
(Scribe changed to Evren Sirin)
Ian Horrocks: admin material
Ian Horrocks: scribes should clean up the minutes they scribed as usual
Ian Horrocks: next f2f scheduled with iswc
Ian Horrocks: we'll setup a poll about f2f date
Ian Horrocks: people should consider about hosting
Ian Horrocks: make a proposal if you want to host
Ian Horrocks: informal telecon next week for people who weren't in the f2f to chat with people who were in f2f
ACTION: sandro set up F2F calendar poll
Sandro Hawke: put a note saying "before you comment look at the wiki to see if issue is addressed"
Jeremy Carroll: add a editorial note at the top of each document saying vocabulary is simplified
Alan Ruttenberg: this is reasonable, any objections?
Boris Motik: I'll do it now
Ian Horrocks: continue with easy keys
Easy Keys
Uli Sattler: two goals: 1) do not prevent future extensions
...2) an easy extension
Bijan Parsia: this is n-ary datatypes
Bijan Parsia: I'll explain easy keys
Bijan Parsia: having inverse functional datatype properties in full generality is hard
Bijan Parsia: we have an idea how to implement but not efficiently
Bijan Parsia: datatype reasoner needs to consider all literals globally
... but keys are very useful
Bijan Parsia: we can do explicit keys on explicit individuals
... if there are two individuals with same key
... infer they are owl:sameAs
... you can write this using DL-safe rules
... basic rule is if x and y are related to z by the key they are same
... people think this kind of functionality is good enough
... but writing these rules is not easy or intention-revealing
... they keys can be restricted to a certain class, too
... you can go further and consider compound keys
... e.g. having both same SSN and same age is a key
Jeremy Carroll: does this only for named individuals or include bnodes?
Bijan Parsia: no bnodes, it is hard to handle
Jeremy Carroll: what are other things I would miss with easy keys vs full keys?
Alan Ruttenberg: how does this interact with punning?
Bijan Parsia: if you are fine with sameAs between individuals it is ok
Bijan Parsia: regarding jeremy's question, missing keys is ok in easy keys
... these are not integrity constratins
... having more than one key should be forbidden
... you can add a cardinality restriction
Bernardo Cuenca Grau: afaik, the difference between proper keys is easy keys only affect data (ABox)
... proper keys can affect TBox subsumption
Carsten Lutz: modulo nominals
Bijan Parsia: yes
Jeremy Carroll: this looks more like rules
Bijan Parsia: yes but we do not want to tell people to use rules
... have special syntax for keys
... the syntax lists one or more properties and the class for which the key is defined
... more than one property is for compound keys
... you are free to mix object and datatype properties here
Jeremy Carroll: can I use property chains here?
Uli Sattler: technically we can add them
Bijan Parsia: we didn't think of them but we can add
... you can write it in DL-safe rules so it is possible
... but for that complexity we might tell people to use rules
... but I'm flexible on this issue
Bijan Parsia: you can also add property chains by a new property axiom giving the chain name
Boris Motik: the semantics refers to Hu which is not in anywhere else
Bijan Parsia: we introduce O predicate that is true for all individuals
Bijan Parsia: that is how you get safety
... Hu does the same for literals
Boris Motik: OWL is two-sorted so you would need two Hu's
Uli Sattler: O is the name of the ontology and use Hu for objects and literals
Uli Sattler: we can have Hu1 and Hu2 separately
Boris Motik: yes you have to have two
Bijan Parsia: lexical difference is an issue
Bijan Parsia: also you can have restriction >16 and <18 which means the value is exactly 17
Jeremy Carroll: how do you write that?
Bijan Parsia: using dataranges and restrictions on facets
Boris Motik: we have unique interpretation and if we drop it it wouldn't be easier
Jeremy Carroll: if I have an inferred value for an easy key for a named individual does the key apply?
Bijan Parsia: yes
Alan Ruttenberg: but not if the subject is inferred
Bijan Parsia: boris, you can search for all literals and then lexically normalize them
Boris Motik: from every constant we need to uniquely interpret it
Bijan Parsia: counter example is addition of a new fact might merge two existing individuals that weren't merged before
Bijan Parsia: you can get literals with existential restrictions
Boris Motik: but it is not in Hu
Bijan Parsia: no, it would be in Hu
Uli Sattler: this might make implementations a little harder but otherwise there are other complications
Jeremy Carroll: are there other things that I should be worried about other than bnodes?
Bijan Parsia: not that I can think of
Ian Horrocks: what if the restriction specifies a range?
... the range can be a finite range then it is not that easy any more as Boris says
Uli Sattler: it is as easy as DL-safe rules
Bijan Parsia: you can always build a disjunction to denote that range
Boris Motik: in OWL I can say greater than 3 which is infinite
... so what do I put in Hu?
... I'm not sure if this is decidable
... also how about complements?
Bijan Parsia: there was another choice to make it more easier
... we discussed that possibility
... but then sometimes you get surprising results
... when you mention one literal explicitly you get new inferences
Alan Ruttenberg: I can make a class whose age is 17 is equal to nothing
... is this still easy with your proposal?
Uli Sattler: mention two surprising results
... saying john's age is 17 and saying john belongs to class of people whose age is 17 would give different results
Jeremy Carroll: is there rdf/xml syntax for this?
Bijan Parsia: we didn't do the work without knowing if wg would like the proposal
Boris Motik: as feedback, I like the general idea but I don't understand details
... without seeing more details I don't understand this is decidable
Bijan Parsia: fair enough
Michael Schneider: this is trivial but where is the datatype defined?
Bijan Parsia: could be with a range restriction
Markus Krötzsch: since this interacts with datarange facets there are no implementations
Ian Horrocks: I agree that I want to see a more formal presentation of semantics and proof for decidability
Boris Motik: the herbrand universe should be finite for decidability
Uli Sattler: not necessarily
Uli Sattler: before going with semantics I want to learn how people feel about oddities
Alan Ruttenberg: how about 1^^xsd:int and 1^^xsd:double as key value?
Michael Smith: int and double are disjoint
Alan Ruttenberg: so the first question is are we happy with easier one with oddities and how much work is needed for complicated version?
Boris Motik: I cannot say without more details
Peter Patel-Schneider: we are happy to see the proposal and would like to see more
Jeremy Carroll: I have an issue with simpler case
Michael Schneider: can you put something in the wiki about not-easy keys
Alan Ruttenberg: we are 5min to 5
Uli Sattler: I want three-fold indication for easy keys
Uli Sattler: you can introduce proper idfp if you don't use the key in restriction
Uli Sattler: option 1 - very easy keys with oddities
... option 2- as we presented
... options 3 - introduce proper idfp without using in restrictions or non-finite dataranges
Alan Ruttenberg: anybidy who doesn't want either?
Alan Ruttenberg: noone
Alan Ruttenberg: large part of wg want at least very easy keys
Alan Ruttenberg: who wants option 2 with uli and Bijan providing prrof?
Alan Ruttenberg: fairly good support
Alan Ruttenberg: who likes option 3?
Markus Krötzsch: you can still have easy keys and proper ifdp
Bijan Parsia: yes
Alan Ruttenberg: thanks for coming
</div>