<alanr> http://www.w3.org/2007/OWL/wiki/Imports

<pfps> you sound much better? is your teleconference cold over?

<pfps> i don't know whether Bijan will be here

I am in the UK, rather than a hotel room in Athens!

<pfps> yes, but for the last while you appear to have been Skyping in, with the usual Skype echo

<scribe> scribenick: Jeremy

Achille: on the three proposals on the Imports page

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

<alanr> Note to Boris, Ian - I added a new proposal 4.3

Achille: like proposal 2, by name - but there are ordering concerns
... desirable that mechanisms for deployment defined in config files, rather than in ontology themselves
... we are seeing ontologies being used say internally rather than on the web
... internal mechanism is similar to that of XML Schema, where schemalocation attribute is a hint to the processor

but the processor can use any internal mechanism to locate the schema

Alan: my proposal (#3) allows you to do this, by importing another file that captures the mapping

Peter: alan how do you mandate the ordering constraints in #3
... RDF does not support ordering constraints

Alan: you load a different file, that includes the original and the mappings

Peter: but that would only work at the top-level, you would need to have control at lower levels too
... to modify the method of importing an ontology you would need to understand the imports-closure of the file you are loading

Alan: can we modify RDF header

Peter: I don't think so.

<msmith> apologies, I had an off by one hour scheduling mistake, just joined

Alan: I looked and thought we could

<alanr> my phone is crap. back in a sec

Boris goes:

Boris: on third proposal
... I didn't understand the use of sameAs to encode equivalence between ontologies
... in DL world this gives ontologies status of individuals and may lead to confusion about how much reasoning is permitted/expected

<alanr> point taken - alternate mechanism for equivalence reasonable

Boris: we shouldn't be mixing logical and metalogical levels.
... while I was advocating #2 (by name) we could do this by having #1 with some disclaimer that permitted tools to do #2.

Achille: I would 2nd Boris in allowing tools to override imports by location
... question to Alan in #3 can I change location without modifying the ontologies themselves?

Alan: yes that's the idea

<Zakim> Jeremy, you wanted to suggest some SHOULDs ....

<alanr> alan notes that tools support different mechanisms - I've experience thrashing on this

<Zakim> pfps, you wanted to talk about overriding intent of ontologies on the web

Jeremy: we could have SHOULDs that put Ontology elements first, while not strict RDF ....
... we could publish vocabs for alternative locations

<Zakim> alanr, you wanted to discuss his use cases versus proposed solution

Peter: overriding a publishers imports statement by providing an alternative location is incorrect, since it changes their intent

Alan: use cases for providing alternative location
... editing local version
... doing testing before publishing/ or checking for comaptible
... another use case allows people to not to have change their namespace
... in versioning scenario what happens if I use latest version, but someone else in imports closure uses a different version

Boris: there are many many use cases, btu specifiying corect behaviour may get out of hand
... there are many many use cases, btu specifiying corect behaviour may get out of hand

<Achille> +1 for Boris's idea of leaving the resolution to the tools

<Zakim> pfps, you wanted to mention that if a designer points to a specific version, then who are we to override ?

Boris: there are many many use cases, but specifiying corect behaviour may get out of hand

<Achille> +q

Boris: we could not specify much, but allow tools to deviate from strict implementation

<Zakim> alanr, you wanted to say outside spec is ok, as long as there is a working version in spec. and to stop losing because protege does it this way

Pfps: If I publish an ontology usign a specific version then that is the version that should be used.
... If I am being stupid, then the correct fix is to educate me, not to import soemthing other than what I said

Alan: Unfortunately stupidity happens; and there should be work arounds for the user
... different tools use different mechanisms for this and it really doesn't work for me
... I waste a lot of time; and imports mechanism acts as vendor lock in

Achille: Addressing Peter's concern about ontology ownership
... from point of view of application developer you may want a local copy

<alanr> example: Narrow scope of ontology: Foaf-dl instead of foaf

Achille: possibly netwoek unreliability ...

<Zakim> pfps, you wanted to mention that other errors also exist

Jeremy: could we spcify imports by location, but provide caching
... and possibly a common vocab to allow tools to interoperate with local caching

Pfps: I don't see why we are picking on imports as something we can override
... ontologies can be broken for many reasons
... and if it is usefull to allow local users to fix imports, why shouldn't they fix axioms too

<alanr> alanr: Notes that processing model makes it clear what is supposed to go there

Boris: an example a colleague simply didn't know what URI to put in improts tag? Physical URI, or logical URI ....

<Zakim> alanr, you wanted to see if we can get consensus that there should be a compatible version across implementations and to say broken axioms can be handled by replacing ontology

Alan: is there consensus that we should specify a mechanism to do this
... I hear a need for tools to override behaviour

<Achille> +1

Alan: I find it a pain that tools do this in different ways; so I would like to see some mechanism standardized ....

<alanr> PROPOSAL: We will define some mechanism for managing imports to handle the mentioned use cases that is in the language, without restricting tools from doing other things too

<Achille> +1 one for Alan's idea of a min import mechanism

<Zakim> pfps, you wanted to ask what the proposal is

+1 to pfps

<bmotik> +0.5 to Alanr's proposal

<msmith> +0 seems that this is more appropriate as a best practices doc than a language feature

pfps: you want to specify something that has nothing to do with the Web, but only to do with tools

alan: yes

pfps: you will need to specify a particular file location for overriding information

Alan: .... we will need to specify something

boris: people are using OWL in many different ways, and proscribing a particular file with resolution information may not work for all tools

<alanr> +1

<alanr> PROPOSAL: We will define some mechanism for managing imports to handle the mentioned use cases that is in the language, without restricting tools from doing other things too

(the proposal is a bit vague)

<pfps> -1

<bmotik> boris: Perhaps we can define some mechanism along alanr's lines, but not as part of a core specification

<bmotik> boris: This mechanism might be defined as part of a "Best practices" document

<pfps> -1 too vague

pfps: we should not be defining solution to offweb issues

<pfps> -1 brings in off-web issues

mike: we need to deal with this in a best practice rather than a specification, so that many tools use the same vocab

<Zakim> msmith, you wanted to suggest modifying proposal

alan: we seemed to be blocked ....

pfps: we can definely improve the wording over OWL 1.0

boris: would Peter oppose this as a best practice?

pfps: no

Alan: I see real benefit in having something in the specification

<Zakim> bmotik, you wanted to ask a question to peter

pfps: I would not oppose some such wording

<bmotik> +1 to Jeremy (more or less)

Jeremy: can we specify that imports is by location; tools may cache, and may need to cache; and we propose a vocab for location mapping

<alanr> ack "caching"

Alan/Boris: don't use the caching word, since it might not be

adjourn ....

<Achille> bye

<bmotik> Bye

This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: Jeremy
Inferring Scribes: Jeremy

WARNING: No "Topic:" lines found.

Default Present: +1.908.582.aaaa, pfps, Vipul_Kashyap, Achille, Alan, Jeremy, bmotik, msmith, Alan_Ruttenberg
Present: +1.908.582.aaaa pfps Vipul_Kashyap Achille Alan Jeremy bmotik msmith Alan_Ruttenberg

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 04 Feb 2008
Guessing minutes URL: http://www.w3.org/2008/02/04-owl-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report