<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