See also: IRC log
<scribe> ScribeNick: msmith
<alanr> I like the fact that imports is by location, but two use cases aren't satisfied - Tool independent redirection to off line versions, for editing purposes, and versioning, as you mention below, and as described on the imports page.
alanr: open for discussion on current state
<jjc> We are discussing the text in http://lists.w3.org/Archives/Public/public-owl-wg/2008Mar/0110
achille: preferred solution would
provide redirection, e.g., as in XML schema with a hint in the
ontology
... by location doesn't give as much flexibility.
bmotik: achille, which solution are you referring to?
achille: owl 1.0 and submission version of owl 1.1
bmotik: but 1.0 was by location, 1.1 spec is by ontology URI, current proposals are by location with implementation override
achille: 1.0 by location is not
what we want
... and I thought 1.1 was same
<alanr> is the word "magic" there?
bmotik: no, 1.1 is by ontology URI (resolution to physical location is left unspecified)
<alanr> -1 to magic
bmotik: this is much about
personal preference. on web is 1 use cae, but in many cases
very difficult
... current proposal is by location with explicit statement
about implementation overriding
jjc: three points
... 1) we mentioned giving suggestion for location to physical
URI. we can write that up
<alanr> hasn't gone away...
jjc: 2) ability to import RDF
files, not OWL files (e.g., the foaf schema). I.e., cases where
ontology label is not present
... i.e., a change to by name might change how we interop with
owl 1.0
msmith: I am comfortable with current proposal (as described by boris) and some sort of hints. but hints need not be normative
<alanr> What is the point of having an ontology header at all? (just to poke at that)
bmotik: to address jjc use case 2, it could be handled by making a special condition when header is not present
achille: this sounds like by name
bmotik: on the web name == location
<alanr> hi peter
achille: concern is that we're
talking about URI, not URL. this is conceptual
... I might phrase this differently. It is import by name, and
by default location should be the same location
bmotik: that's the way I want to look at it.
achille: ok. this is a matter of taste and perspective
<pfps> it needs to made readable
alanr: jjc's point on files w/o
ontology header is new and important
... I like assumption of import by location
... I like minimum specified for import redirection (mapping of
names)
... can we discuss why we need ontology header at all? I don't
see need to check name vs location loaded from
pfps: my recent email covers my
position
...
http://www.w3.org/mid/20080307.100929.46881308.pfps@research.bell-labs.com
jjc: I'd prefer *informative* mapping rules b/c this is an interoperability point that is not too important
<pfps> +1 to jeremy's position
<Zakim> jjc, you wanted to suggest *informative* remapping rules ...
<bmotik> +1 to jeremy
<alanr> -1 to not important
bmotik: if name and location should be the same, then it is dangerous if header is different. additional check, in case where header is present, is helpful.
<Zakim> bmotik, you wanted to discuss checking ontology headers
alanr: I judge importance of
mapping higher than stated
... curious to what damage would be with simple normative
mechanism
... specify mapping file, tool should respect unless it is
explicitly overridden
<pfps> what is an "ontology header"?
<pfps> what is an "ontology element"?
alanr: re ontology header, I *thought* that avoiding repeated import of the same ontology would be presented as a motivating use case
<pfps> yes, but which one?
<pfps> the RDF situation is completely broken
bmotik: ontology header is naming triple
alanr: as pfps points out, there
can be more than one
... I've never run into the case where tool helps user based on
checking the header
<alanr> jjc - how about saying what the damage is for having normative mechanism
<pfps> that doesn't work unless you change imports and ontology properties
bmotik: I agree the RDF case is broken, but that is b/c there isn't a ontology to graph mapping
<Zakim> jjc, you wanted to argue for ontology header (as devil's advocate ....)
pfps: a couple problems on rdf side re: what is the ontology?
<bmotik> bmotik: We could fix RDF to assign at most one URI to each RDF graph
<alanr> we could change this
bmotik: in many cases ontology is not explicitly typed
jjc: I think to be legal 1.0 is must be explicit
bmotik: I don't see that in many cases on the web
jjc: type triple is in imported, not importer
alanr: what's damage of normative mechanism
jjc: wg are bad at specifying anything. design by committee is wrong answer unless required.
<bmotik> But would we close this down?
jjc: being normative would prevent implementers from being smarter than us
<bmotik> Developers could always implement *additional* mechanisms...
<alanr> ack
alanr: agree with boris' irc
comments. normative mechanism is only a baseline and any other
mechanism could override the normative mechanism
... at least then, we would have the basic interop
<alanr> alanr alanr
<Zakim> alanr, you wanted to say that all redirection mechanism boil down to the same thing and to add my suggestion allows override
alanr: current tools all have the same basic mapping approach
<Zakim> pfps, you wanted to talk about installation difficulties
jjc: ontology header useful for metadata about the ontology
pfps: worries about working
system that doesn't have root privileges
... you're talking about a common mapping between multiple
tools and multiple users
alanr: interop here means moving from tool to tool w/o modifying my ontologies, or not changing mapping mechanism
pfps: I'm unconvinced, you're only solving 1/10th of the problem
<bmotik> I agree with Peter
pfps: it will only work sometimes, therefore cause more problems than it solves
<bmotik> +q
pfps: normative mechanism should facilitate collaborative editing
<Zakim> jjc, you wanted to support peter
alanr: that's a different use case
jjc: when talking applications vs. ontologies worrying about overcoming things like security issues is necessary, and those things are outside our area
bmotik: I'm fine saying there is
some mechanism, there need not be an override
... this could be difficult b/c, e.g., where is the mapping
file located? local homedir, on web, file open dialog,
database?
<alanr> you have to give a uri to your tool somehow.
bmotik: it would be useful, but I don't think it is necessary
<Zakim> alanr, you wanted to ask what root privs have to do with anything
bmotik: and it may be too
complex
... doing so may require too many assumptions to be useful
alanr: I don't see the
complexity
... any tool needs some way to specify where an ontology is.
the mapping file requires the same thing.
pfps: if you had, any tool could point to some location which would contain some mapping files, then its easier, but then user must arrange to have the mapping files be the same
<bmotik> +1 to peter
pfps: I see problems for
implementers b/c functionality would only be used
sometimes
... the inconsistency would be problematic
<bmotik> +q to give an example of a system that thes not use files at all
alanr: this makes everyone suffer b/c some people will do silly things. but we know this can be useful in some cases
jjc: maybe a tool specific URI
format. so remapping interoperably is already limiting storage
types
... e.g., jena users have complained about internal URIs that
aren't meant for interoperability
bmotik: ontoprise people use ontologies without any files b/c they are all stored in a database. Requiring a "file" doesn't make sense
<alanr> ao
<Zakim> bmotik, you wanted to give an example of a system that thes not use files at all
<Zakim> alanr, you wanted to ask how this is any different from import by location? and to ask where we have consensus
alanr: do we agree on import by location?
<jjc> +1
bmotik: with override
alanr: yes.
<jjc> +1
<Achille> +1 with override
+1
<bmotik> +1 to import by location with an override
alanr: not in agreement on what is in ontology header. there are issues with current rdf version. we don't have a mechanism to fix that.
<bmotik> 0
alanr: consensus on informative redirection being acceptable?
<pfps> I'm willing to have the spec say that tools can override
<jjc> +0
<bmotik> +0 because I see it as useful, but if it costs us too much time to come up, then I would drop it.
<Achille> +1
alanr: we agree we might specify *informative* method for redirection
?
<pfps> +.5
+0 with boris' comments
alanr: we have close enough to agreement
<pfps> and versioning
<Zakim> jjc, you wanted to note weakness of vote for informative mechanism
no one objects
jjc: there were 2.5 votes for informative mechanism, which appears to be below consensus
-1 to raising this in main wg
jjc: maybe we should raise at main wg
alanr: just meant as straw poll, to see where we were
<bmotik> +q to answer about the DB case
alanr: case of database storage
of ontologies, if imports are specified by location we don't
handle those cases
... override makes it possible
<Zakim> bmotik, you wanted to answer about the DB case
bmotik: yes. the database case is something a tool can do
<alanr> bye
bmotik: point is define as by
location with override. then tool can do whatever it
wants
... if informative mapping, then tool can ignore
... if normative, it would constrain tool
alanr: you may have
misunderstood
... proposal is 3 levels
... 1) by location (in ontology)
... 2) mapping specified
... 3) override by tool
bmotik: how did we get there? that's not how I understood the straw poll
alanr: I was addressing the database case. and whether it would make a *normative* mapping mechanism worse
bmotik: normative mechanism puts assumption on how tools work with ontologies
<alanr> a tool can do whatever it wants. But if it does nothing, then it respects the mechanism specified.
<pfps> +1
<Achille> +1
alanr: sounds like one more meeting, then go back to wg?
<bmotik> +1
+1
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) Succeeded: s/rediction/redirection/ Found ScribeNick: msmith Inferring Scribes: msmith WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: Alan_Ruttenberg IBM P13 P4 Peter_Patel-Schneider ScribeNick achille alanr bmotik jjc msmith pfps sandro trackbot-ng You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy 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: 10 Mar 2008 Guessing minutes URL: http://www.w3.org/2008/03/10-owl-minutes.html People with action items: 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]