See also: IRC log
<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[End of scribe.perl diagnostic output]