From OWL
Jump to: navigation, search

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

The agenda was taken up in a non-standard order.


Bijan Parsia: I'll note that the charter doesn't quite require owl rechartering probably isn't required but could be good for extra clarity

Alan Ruttenberg: We will start the teleconference with the OWL Full discussion. [Scribe assist by Peter Patel-Schneider]
Alan Ruttenberg: Peter and Jim, do you have anything to say about the reasons for OWL Full [Scribe assist by Peter Patel-Schneider]

Peter Patel-Schneider: We did OWL Full because it was mandated.

Peter Patel-Schneider: I don't know if that is what you want to hear. I wont say who mandated it.

Bijan Parsia: There's two questions: 1) Why *an* owl full and 2) why *this* owl full
James Hendler: OWL Full was the result of a major consensus-reaching compromise. One group wanted OWL DL, another group didn't. Inverse datatype properties were a key issue -- one group would object to including it, one group would object to not including it. [Scribe assist by Sandro Hawke]

James Hendler: some people thought OWL should be DL'ish, others not

Rinke Hoekstra: OIL had something called 'heavy OIL'

James Hendler: The key thing WebOnt decided, which is perhaps open to discussion, vocabulary terms like owl:X would be in both languages, although perhaps with restrictions on each. Each side had exactly the same vocabulary terms covered.

Jeremy Carroll: I felt what happened with OWL DL and Full, had to do with two different groups coming together. Peter represents the DL academic community, which had a strong idea where it was coming from. Meanwhile, there was an RDF community. Both communities can gain real insights from each other, but there are arguments and difference. Like any marriage, both sides have some good points and some bad points.

Bijan Parsia: Peter comes from an industrial background...see classic

Bijan Parsia: It's a conceptual error to regard OWL Full as a unitary phenomenon. There are a lot of different parts to it, and they each have their own story. EG classes as instances. Very different uses cases. EG annotations. ("my property was made by me, and modified on some date" -- different from modeling.)

Bijan Parsia: I think there is an OWL Full is because there was to be a gap between what some people wanted and what some implementors (doing complete implemtnations) could do.

James Hendler: The path to the split was important. A lot of the design on the DL and Full sides were influenced by what happened when. We have the option to rationalize it now.

Bijan Parsia: I'll note that the RDF semantics were also being designed (in a sort of death march) and "fitting" with that was seen as a requirement

James Hendler: A lot depended on the temporal ordering of events. We now have the option to rationalize it.

Peter Patel-Schneider: Compatibility with RDF was requirement, and yet RDF Semantics weren't designed yet. If the ordering had happened differently, then the semantics of RDF might have been different. The FOL view of the world and the Triple view of the world were split. Once RDF settled on the Triple view, we had to live with it.

James Hendler: pfps is right - RDF-based was in our charter.

Bijan Parsia: "applications" using owl full really requires teasing apart the parts of owl full

James Hendler: (60% of RDF data is FOAF, which is is not in DL)

Bijan Parsia: But here's a good example...primarily the lack of DLnessin foaf is use of inverseFunctionalDatatype properties which is perfectly first order.
Zakim: alanr, you wanted to talk briefly about foaf and to ask if we want OWL-FULL to mean not OWL-DL and to ask is there an OWL Full, or are there just OWL Full features

Jeremy Carroll: People inside HP and out find great use for "reasonable" use of OWL-Full, eg subclass list vocabulary, but NOT "messing with the furniture". Having a rule engine as an underlying engine is important. [??]

Alan Ruttenberg: FOAF deviates from OWL DL in a few places. Inverse-functional-property on strings (eg mailbox hashes), and annotations on properties.

Alan Ruttenberg: I heard different descriptions of OWL full: Everything not in OWL DL. Or in terms of features. People don't often talk about OWL Full as a language with this and that features. Mostly they say they are in OWL full because they are not in OWL DL. Many people just want to use one or two features, does OWL full have to be a "whole" language?

Bijan Parsia: Think of OWL full as having several categories of addition: 1. notational variants of FO-constructs not in OWL DL, 2.: rules; 3.: metamodelling; 4: arbitrary graphs of b-nodes 5. non-simple riles in cardinality restrictions, 7. hilog semantics; 8. reflections on vocabulary [shadow builtins -- RDF List vs what you say about builtins should change meaning of ontologyes eg domain/range on rdf:type]

Alan Ruttenberg: uli thinks also of non-simple roles in cardinality restrictions (good one for the record)

Bijan Parsia: Main use: push the bounds of OWL DL a bit to make their applications / tools fit; Semantic flexibility is nice, helps interoperability, but we shouldn't overformalize this

Alan Ruttenberg: note reasoner(bijan) =def sound, complete, decidable ?

Michael Schneider: Great point of OWL full: accepts every RDF graph; people can have standard RDF data as used by SPARQL and incrementally add semantics to certain but not all properties. This gives you more flexibility than you have in OWL DL

Zakim: jeremy, you wanted to talk about architectural role

Jeremy Carroll: One of the raisons d'etre of OWL Full is architectural. The RDF view puts semantics on top of triples, and 'semantic extensions' of RDF allow for multiple additional semantics to be layered on top. OWL Full is one of these. OWL Full includes OWL DL, I don't much like it being described as not OWL DL.

Bijan Parsia: I didn't understand the last bit...what's the power play?
Jeremy Carroll: my recent comments on public owl dev suggest that use of 'not' to define primary categories can be a statement of power
Jeremy Carroll: e.g craft = art that is not fine art, is a statement about the economic interests in fine art

James Hendler: My users don't care about the semantics; they work operationally; they don't want to use OWL per se; they find OWL useful for some things they are doing; this applies to many people from the web 3.0 community. Using OWL DL forces them to use things they don't care about

Jeff Pan: Shall we not provide a semantics for OWL Full then
Alan Ruttenberg: alanr asks, loop constructs with enumerated data types ok in java?

James Hendler: Owl full is a misnomer; OWL Full is a vocabulary; OWL DL uses it

Uli Sattler: I like Jim's "loop" metaphore, but I have seen people happily *not* using certain language features to ensure good performance/no stack overflow...

Bernardo Cuenca Grau: We should distinguish syntax and semantics; Jim's users want syntax

Jeff Pan: RDF is more than syntax, it provides a data model too

Bernardo Cuenca Grau: Do we only want an RDF syntax for OWL 1.1, or do we want also a semantics for the triples? If people only want syntax, they don't care about the semantics of the triples

Bijan Parsia: If users don't care in the semantics, do you see harm in assigning a semantics that is .... [??]

Zakim: jhendler, you wanted to clarify re: "semantics"

James Hendler: it's not that users don't care about the semantics; they care about the semantics of, say, same-as. But they don't care about provably getting their reasoners right. An axiomatic semantics may serve that community better than a model-theoretic semantics

Bijan Parsia: this is a presentational issue; I was asking for the actual semantics

James Hendler: It is important to get the semantics right, but people do it at their own risk; a good example is linking to another ontology without declaring the type.

Zhe Wu: some users are using OWL full features such as same as; they care about the semantics, have an intuitive understanding;

Jeff Pan: So the users care the semantics of some constructs but not others
Bijan Parsia: I don't think we have time on the telecon, but I'll add that I'd like to have correct and complete implementations of the language. If people write custom subset reasoners, we need to spec some level of interop between the ad hoc ones and the ones aiming to be complete. People move between the two types of systems quite a bit.

Alan Ruttenberg: we need to define a vocabulary, and a minimal operational semantics; a DL + feature semantics was proposed, without saying how all work together

Bijan Parsia: I don't understand the question

Alan Ruttenberg: Is an OWL Full semantics along the lines of 1.0 something we want in this working group? Let's have a strawpoll.

Bijan Parsia: We should separate semantics presentation from semantics. I want to change the semantics of OWL full, and would like to stick with model theory for presentation

Jeremy Carroll: Clarifies Strawpoll: Do we want an Owl Full semantics as a delta of the OWL 1.0 full semantics?

Rinke Hoekstra: I like the delta approach of Jeremy, but don't immediately understand in what ways a Full 1.1 semantics would differ from Full 1.0...
Sandro Hawke: 0? totally depends on other options.
Evan Wallace: 0
James Hendler: -1 (propose we explore other options then a feature by feature model semantics)
Carsten Lutz: I agree: depends on other options
Jeremy Carroll: +1
Jeff Pan: I don't understand the delta approach either
Ratnesh Sahay: 0
Peter Patel-Schneider: +0 depends on the delta (remove everything, then add some stuff?)
Zhe Wu: i don't understand
Ivan Herman: 0
Markus Krötzsch: 0
Jeremy Carroll: bye conflict ...
Uli Sattler: i guess I will tend to a minus
Achille Fokoue: 0 need more info on the nature of the delta
Rinke Hoekstra: +0
Michael Smith: 0
Boris Motik: --0
James Hendler: -1 again (so it is in right place - but to explore other options)
Carsten Lutz: -0 as far as I can tell without knowing the alternatives
Bernardo Cuenca Grau: 0
Bijan Parsia: -0
Elisa Kendall: -0
Michael Schneider: +q

James Hendler: q+ to suggest we go a couple more minutes to get some actions defined, but then move this to email
Zhe Wu: that sounds good to me
Evan Wallace: we need to see the set of alternatives on the table
Rinke Hoekstra: +1 to evan

Michael Schneider: People didn't understand what delta means here; we should explain before we can vote

Peter Patel-Schneider: +1 to evan - what are alternatives?

ACTION: mschneid to explain what delta to 1.0 semantics means

Ian Horrocks: Does anyone have any idea as to an alternative?

Ivan Herman: I think we need to have a clear view of what the alternatives are before voting. We need a feeling what it costs in terms of time/energy. What would an operational semantics mean? We need this before making decisions.

James Hendler: I believe that if long term (maybe not out of this WG) we see a path that takes us to "one OWL" it would be a big win

ACTION: Alan to describe what he means by a "feature at a time" semantics

ACTION: hendler will describe an approach to an "operational semantics" for OWL Full

Previous Minutes

PROPOSED: Accept Previous Minutes

Peter Patel-Schneider: -1 no chair, typos, ...

Action Item Review

Markus Krötzsch: Action 70 was completed, see
Peter Patel-Schneider: Pending Action Review - 77 and 39 done
Michael Smith: agreed, Issue 76 was postponed when it was created

Issue Discussions

Issue 3

Alan Ruttenberg: Peter is suggesting that we restore anonymous individuals as they existed; existential semantics. If we adopt skolemization, then go back and change it again

Peter Patel-Schneider: ok

Zakim: pfps, you wanted to mention that that is not Issue 3

Michael Schneider: Has it really been existential semantics?

Peter Patel-Schneider: owl 1.0 was existential semantics; whether people implemented or not is separate issue

ACTION: pfps send out proposal for minimal change for issue-3

James Hendler: fwiw, since we've put off the Use Cases document it would help us non-logicians (or old fashioned logic types) if proposals for things like this could include some common sense use cases

Issue 68

Bijan Parsia: p domain c.
Bijan Parsia: s p o.
Bijan Parsia: ==> s rdf:type c
Bijan Parsia: If we have p rdf:type DataProperty and p rdf:type ObjectProperty
Bijan Parsia: then instead of going to rdfs:domain
Bijan Parsia: You go to owl:objectDomain (or something similar)

issue 68 postponed; should be discussed with Jeremy

Bijan Parsia: (can't we solve this by *adding* the more specific domain as well as the rdfs:domain?)

Issue 91

Boris Motik: When you say there is no ontology property, do you mean there is no well-known ontology property, or there is no ontology property as such?

Bijan Parsia: we should add the builtin list of ontology annotations
Peter Patel-Schneider: to what end?

Rinke Hoekstra: We should add the builtin list of ontology annotations

James Hendler: +1 to bijan

Alan Ruttenberg: This is separate from the roundtripping issue, we should not treat them as one.

Boris Motik: We can easily mention the list of various anotation properties in the current documents. We could then close the issue potentially

Alan Ruttenberg: any objections?

Peter Patel-Schneider: +1 to editorial
Bijan Parsia: +1 to editorial
Rinke Hoekstra: +1
Ian Horrocks: Sounds good to me!
Ivan Herman: +1
Boris Motik: +1 to editorial
Uli Sattler: +1
Martin Dzbor: +1

ACTION: bmotik2 to Edit the secification to mention the well-known ontology properties in the spirit of OWL 1.0 and thus possibly resolve ISSUE-91

Issue 95

Peter Patel-Schneider: Simple way forward: state that the only facets allowable are those in XML schema datatypes; tiny change to the syntax

Uli Sattler: +1 to Peter

Peter Patel-Schneider: User-defined datatypes should have in the spec which facets make sense for them

Bijan Parsia: User defined types are constrainted by their base type
Bijan Parsia: New *base* types must spec what facets (new or old) are possible

Michael Smith: Agrees with peter

Peter Patel-Schneider: I have a syntax change that fixes that issue
Alan Ruttenberg: q+ to ask boris about datatype restrictions such as pattern matching

Boris Motik: You can currently put a datarange restriction on non-integers; difficult to implement; this should be changed; argument of datatype restriction should be a datatype

Michael Smith: That doesn't seem so important

Zakim: alanr, you wanted to ask boris about datatype restrictions such as pattern matching

Boris Motik: Issues with compatibility; is non-integer compatible with min-inclusive? Facets only on datatypes, not datatype expressions

Alan Ruttenberg: q+ to get clarification from boris - What about Mike's proposal re: Value space. Also, what about saying no facets allowed for expressions

Jeff Pan: one solution about the negation issue is to specify the groups of datatypes intended to be used with the ontolgoy
Peter Patel-Schneider: [datatypeRestriction] := ( datatypeRestriction | datatypeURI )
Peter Patel-Schneider: '[' datatypeFacet restrictionValue { , datatypeFacet restrictionValue } ']'
Peter Patel-Schneider: If the datatypeURI involved is an XML Schema datatype then the datatypeFacets and restrictionValues have to be valid for that datatype.

James Hendler: We are formalizing things that are maybe better not formalized; lets go for a minimal solution and not fix how to handle the other cases at this point of time

Uli Sattler: Jim, this is exactly what we are proposing?

Zakim: alanr, you wanted to get clarification from boris - What about Mike's proposal re: Value space. Also, what about saying no facets allowed for expressions

Bijan Parsia: Some facets are always applicable; things that restrict the lexical form. Not very interesting to spec, though.

Ivan Herman: What about Lee's question on the lang tag on strings?
Michael Smith: I don't think any of the facets we have now work on lexical forms

Jeff Pan: in a datatype group, only the allowed facets are allowed to be used
Bijan Parsia: I think that a simple syntactic restriction is the best way forward
Jeff Pan: we might need something a bit more than that
James Hendler: boy I wish we had a use case or two to anchor this description to real world cases...

Michael Schneider: we could allow application to datatype expressions, as long as they are "compatible" with the facet

Ian Horrocks: Let's do something simple; hard to imagine that in application we need more than basic facets on basic datatypes; solution like in OWL 1.0: this is what we support, people can go beyond that but we don't spec it

Uli Sattler: I thought that this is the current suggestion
Jeff Pan: +1 to simple solution that works
James Hendler: +1 to Ian re doing something simple in this apace

Michael Schneider: I meant: table with fixed set of datatypes and fixed set of facets which described applicability

Ian Horrocks: This sounds reasonable (the table I mean)
Ian Horrocks: Although I would prefer to simply defer to XML as far as possible
Uli Sattler: what about the table/descriptions at
Ian Horrocks: Table uli pointed to looks reasonable
Michael Schneider: My counter example for *not* having facet definitions on complex dataranges: oneOf("2"^^xsd:int, "3.14"^^xsd:float, "hello world"^^xsd:string)
Boris Motik: They are bad!
Michael Smith: they are certainly hard
Uli Sattler: They are wonderful!
James Hendler: +1 to making complex dataranges "unspecified" from this version of OWL
Bijan Parsia: Can we merge this with n-ary?
Uli Sattler: Yes, please!
Bijan Parsia: Boris, see:

ACTION: smith to send email describing what may be lost if facets are only applied to datatypeURI

ACTION: bmotik2 to Change the spec to add a table with facet-datatype compatibility