F2F1 Minutes Session 3

(Scribe changed to Markus Krötzsch)

Imports

Slides for this session: Media:pfps-f2f1.pdf (go to page 5)

Wikipage: http://www.w3.org/2007/OWL/wiki/Imports

Peter Patel-Schneider repeats imports definitions from OWL DL, OWL Full

(compare http://lists.w3.org/Archives/Public/public-owl-wg/2007Nov/0565.html)

Peter Patel-Schneider: differences relate to whether ontology names or locations are assumed in import statements

Bijan Parsia: not all ontologies have names, right?

Peter Patel-Schneider: yes, only importable ontologies need a name.

Peter Patel-Schneider: this appears to be a bug

Boris Motik: (1) there should be only one kind of import, not three

... (2) it should be possible to reconstruct the location from whic some statement was imported from, e.g. for editing

Bijan Parsia: the name and location can be different, the question is how to deal with it. This seems to be agreed on.

Peter Patel-Schneider: OWL1.1 imports are based on ontology names only

... this is completely different from OWL1.0, where the name must be the location.

... We do not have XML inclusions (a mechanism working with location only).

... Summing up there are two different designs: name and location based importing.

Peter Patel-Schneider: various questions arise

... (1) should every ontology (be forced to) have a name?

... (2) should name and location be the same (i.e. should the name always indicate the location)?

... (3) should imports be by name or by location?

Jeremy Carroll: this seems to be a general web architechture issue.

Bijan Parsia: in general URIs are not locations, but there might be (multiple) hints for actually finding the document.

Peter Patel-Schneider: versioning is another problem

Alan Ruttenberg: this goes beyond the importing issue

Peter Patel-Schneider: every importable ontology needs some location, but it need not be on the web

Boris Motik: a typical use case is that two ontologies (one importing the other) reside in some file repository and then are moved to the web. How do you support this?

... locations change over time

... this is not just a caching issue

... What they are doing in XML Schema may be a good solution.

... When importing an ontology, I do not care where it lives. It might even have many copies.

Alan Ruttenberg: I suggest that names and locations might be different, but importing one ontologies from some location should also make this location a name for the ontology.

Bijan Parsia: I do not understand the proposal

Alan Ruttenberg: every importable ontology has a name which is also a location, but it is possible that the same ontologies have different names in the sameAs-sense.

... importing may lead to the inference (?) that two names refer to the same ontology.

General agreement that further clarification is needed.

Alan Ruttenberg: every name should be a location, they are linked together.

... just if a name does not match its location, then this alternative name should be deduced.

Bernardo Cuenca Grau: when you have an ontology name occuring in documents in different locations, how do you know they are the same?

Boris Motik: well, it is just *the*, say, Wine ontology

Bernardo Cuenca Grau: but there could be versions

... e.g. if someone adds axioms

Boris Motik: this is not specified, but a similar mechanism is found in including classes in Java. Java uses names but the application environment must resolve the locations.

Jeremy Carroll: there are two cases: creating an ontology and publishing it, and the reverse, downloading and caching an ontology from the web.

... we should concentrate on the web/caching aspect, not on the publishing aspect.

Evan Wallace: Many people in ISO want to use URNs as a name, and these are not locations.

Alan Ruttenberg: I would also say that an ontology name is a URI, not always a URL, but to import it, you need a location which would then become a synonym.

Achille Fokoue: the inclusion mechanism of XML Schema (XML Schema import not XMLinclude) is a good solution.

... names should not be tied to locations, but further sources should be used to resolve names.

Alan Ruttenberg: is this consistent with my proposal for having many locations for some ontology?

Achille Fokoue: yes, I would like some default mechanism that can be overwritten to specify alternative locations

Boris Motik: I have two points.

... (1) how many ontologies are really on the Web?

... (2) we should not specify in detail what tools are supposed to do when looking for ontologies

... It would have been easier to leave tools some freedom for determining ontology locations, e.g. similar to CLASSPATH in Java

Ian Horrocks: Re (1) appliations may still refer to the web, but ontologies might stilll be local to some server

Boris Motik: but aren't there also relevant uses of ontologies without any Web?

Bijan Parsia: it is not out of scope to consider ontologies that are not on the web

... I am disagreeing with Alan.

... I often created local copies of ontologies to modify them, while keeping internal names.

... It shoud not happen that those modified copies then are deduced to be the same as the original one.

... I do not see what Alan's proposal buys us.

Ian Horrocks: summing up, the problem could be that multiple (versions of) ontologies have the same name in their header, and those should not be considered the same.

Alan Ruttenberg: this would only happen if both were imported.

... Considers, e.g. having three variants of one ontology:

... B, B', B''

... depending on what you import you may get either

... only if you import two at one time, these would be merged.

Bijan Parsia: but didn't you say that locations and names then get equated (sameAs) on import. Why would this be good?

Ian Horrocks: these details should be discussed here, and the discussion must probably be taken offline at some point.

... including clearly written-up proposals.

Alan Ruttenberg: responding to Jeremy saying that we should leave this to the caching mechanism. The reason that I would like to have "location punning" on names is that I would like to use different tools at one time.

Sebastian Brandt (guest): I would like to partially agree with Boris: ontologies are often used offline to make money, but they still are developed online.

Matthew Horridge (guest): when developing tools, we only found it reasonalbe to treat ontology URIs as names. Protege uses a lookup table to map onologies to local files.

ACTION: Bijan to extend the wiki with information on imports and restructuring it if needed (with Sebastian)

ACTION: Alan Ruttenberg to write up his proposal on dealing with imports

Rich Annotations

Slides for this session: Media:pfps-f2f1.pdf (pp. 5-7)

Peter Patel-Schneider: basic ideas of rich annotations

... allow arbitrary syntax as annotations, including annotations

... annotations separated into "spaces" and some spaces may indicate that tools must understand the respective annotations (for extensions)

(Peter Patel-Schneider presents syntax slide)

Peter Patel-Schneider: keywords mayIgnore and mustUnderstand describe whether or not annotations are essential for semantics

... yes, annotations with "mustUnderstand" may change the semantics, also of existing constructs

... Each annotation belongs to some "space", given as part of the annotation syntax.

... There is a "default space" for annotations without explicit space annotations.

Bijan Parsia: the term "annotation" is ambiguous. In OWL1.0 it was something given to an annotationProperty. In OWL1.1 it can be any piece of syntax.

Peter Patel-Schneider: Annotations may even exist without relating to any OWL object.

Alan Ruttenberg: do the axioms of the containing ontology also belong to each annotation space?

Bijan Parsia: no, unless one would import it explicitly.

Boris Motik: I do not understand the idea of "annotation spaces"

Peter Patel-Schneider: this is because some annotations are semantic extensions, that should be keeped separate from other annotations.

Sebastian Brandt (guest): I have another use-case: I have some annotations that are just user documentations, some that contain "code" that is used by the application, and even some that are generated automatically by my applications.

Jeremy Carroll: we should have a worked example that illustrates this

Bijan Parsia: the Pronto extension to OWL provides some example

ACTION: Bijan to improve examples for rich annotations.

Boris Motik: it would also be useful if someone could explain in detail how to use this mechanism, starting from ontology creation up to external reuse.

Bijan Parsia: I can do that after coffee

Alan Ruttenberg: is there going to be an RDF serialisation to this?

Bijan Parsia: yes

Alan Ruttenberg: do annotations then distribute over differnt files?

Bijan Parsia: no, we can use reification to add extra annotation-space information

... but there are many possibilities

Peter Patel-Schneider: I think the idea of annotation spaces changing the semantics of OWL is what is most controversial

Bijan Parsia: semantic annotation spaces need to have a spec, e.g. to include RIF rules into OWL documents.

... this spec then defines the intended semantics.

... The annotation space has a URI that may specify this semantics.

Peter Patel-Schneider: annotations usually have no semantics, exceptions being the mustUnderstand annotations that must be taken into account by tools in an adequate way.

Ian Horrocks: we did only talk about rich annotations, but not about the other OWL1.1 extensions to the OWL1.0 mechanism.

... this should also be discussed.

Peter Patel-Schneider: we can do that in the compatibility session tomorrow.

Coffee break.