<uli> aha, this explains things

<scribe> ScribeNick: msmith

<bmotik> > Zakim, who is on the phone?

<sandro> it's always slow at the top of the hour.

<bcuencagrau> Zakim ??P8 is me

<pfps> ack ??P5

<IanH> ack +0186527aacc

<IanH> ack ??P2

roll call

agenda amendments?

ianh: no agenda amendments

PROPOSED: Accept Previous3 Minutes (04 June)

<pfps> 4 june minutes look acceptable

RESOLUTION: Accept Previous3 Minutes (04 June)

Accept Previous2 Minutes (11 June)

<pfps> 11 june minutes look acceptable

<IanH> +1

PROPOSED: Accept Previous2 Minutes (11 June)

<uli> +1

RESOLUTION: Accept Previous2 Minutes (11 June)

Accept Previous Minutes (18 June)

<pfps> 18 june minutes are *perfect* :-)

PROPOSED: Accept Previous Minutes (18 June)

<IanH> +1

RESOLUTION: Accept Previous Minutes (18 June)

f2f3

ianh: clarify status on http://www.w3.org/2007/OWL/wiki/F2F3_People

pending review actions

ianh: on action-160 wasn't there question on top/bottom in profiles? keys in profiles?
... there was an action on uli re: top/bottom in profiles

uli: I sent an email on top/bottom in dl-lite. diego?

calvanese: dl-lite has no top concept... there is no point to having it. we don't believe it would impact properties, but there is not point
... if it doesn't change computation properties, it is just by chance
... you don't gain any expressivity

ianh: its already that it doesn't add expressive power to DL

calvanese: yes, b/c you have nominals, that might not apply to profile which is strict subset

uli: reason to add is not to add expressivity, it is to add useful syntactic sugar
... e.g., rooting a property hierarchy from a top property

ianh: with profiles, ruling things out is costly rather than having them
... we should only rule things out if e.g., they have adverse impact on properties

msmith: +1 to ianh

calvanese: I partially agree. adding construct gives indication it is to be used. this may have bad impact, even if it can be simulated with existing constructs

<JeffP> +1 calvanese

calvanese: similar argument for dl-lite profile

bmotik: only profile now including top/bottom is EL++
... I don't think property must be in profile for editor to hang things off it in UI

<uli> 1-

ianh: we had discussion about top/bottom being useful and addressed if it *tempts* users in a negative way
... it seems we can have it in dl-lite

calvanese: I'd like to check the details on whether we can have it

ianh: revisit this in future telecon
... top/bottom is in el++

bmotik: not in owl-r

ianh: should we action someone to investigate easy keys

bmotik: no. its clear no easy keys in dl-lite
... I added it to owl-r

<scribe> ... unknown for EL++

jeffp: top/bottom in el++ ?

bmotik: yes, checked with Carsten

jeffp: it doesn't have nominals

ianh: yes, presumably it doesn't hurt

bmotik: yes, it doesn't hurt

jefffp: what about el+

<bcuencagrau> EL++ without nominals

bmotik: what's el+

jeffp: el+ is supported by CEL

<JeffP> ok

ianh: a bit off topic, we're only concerned with EL++ profile, not other fragments
... interesting that CEL doesn't support all of EL++ since we'll need to follow-up moving forward the recs

calvanese: follow-up on keys in dl-lite, and boris's comments on it adding recursion. we'd like to see some version of keys, could we consider a restricted version.

ianh: are you willing to take action

<scribe> ACTION: calvanese to investigate top/bottom roles in dl-lite [recorded in http://www.w3.org/2008/06/25-owl-minutes.html#action01]

<trackbot> Created ACTION-162 - Investigate top/bottom roles in dl-lite [on Diego Calvanese - due 2008-07-02].

 ACTION: calvanese to investigate easy keys in dl-lite

ACCEPT ACTION-160 as completed

due and overdue actions

ianh: action-155

<pfps> could we have a pointer to the document from the ACTION-155 page?

ianh: there is a document, we also need implementation
... yes, we should add pointer to doc to action

<ivan> no

ianh: bump date forward for action-155 pending arrival of an implementation?
... ok, that's what we'll do
... action-156, action-157

alanr: push them both a week

ianh: ok

issue-21 and issue-24

ianh: proposal to resolve says "per pfps email and subsequent discussion", are we really here? it doesn't seem complete

alanr: we're close, have 1 issue open
... is inconsistent independent of header? bmotik and I disagreed
... it may be case inconsistency is noticed by user, not maintainer, we'd like to state this

bmotik: one ontology saying something about another is recipe for disaster
... breaks encapsulation. let's people say anything about anything

<alanr> how is this different from having axioms on a class in two different ontologies?

<Rinke> Not sure whether this has anything to do with the issues per se? Seems that the issues are being overloaded with side-issues that prevent them from being resolved.

bmotik: detecting these incompatibilities and maintenance could get out of hand

<alanr> detecting is trivial

alanr: I'm not persuaded

bmotik: allowing one ont to say something about another seems to me as a conceptual hack

<Rinke> +1 to separate issue!

alanr: you're arguing conceptual integrity vs. use case from personal experience
... we can spin this off to another issue and resolve the rest

uli: +1 on separate issue
... +1 to bmotik that this will open can of worms and may be difficult to explain behavior

ianh: I see what you mean, just as you don't have control over another on, you may not have control over statements saying what onts are incompatible

bmotik: already what we have is an improvement

alanr: not sure that's the case for owl 1

bmotik: but there was no semantics

alanr: yes, problem was no teeth to semantics

bmotik: tool is more that welcome to do this. seems to be extrapolating from one use case

ianh: given we have agreement other than this, can we move forward closing ISSUE-21 and ISSUE-24 and open new issue to discuss versioning?

alanr: incompatible with, not versioning

<pfps> fine by me

<Rinke> +1

ianh: yes, incompatibleWith

<IanH> PROPOSED: resolve Issue 21 and Issue 24 Imports and Versioning, per update from Boris, Peter's email and subsequent discussion, modulo opening new issue on incompatibleWith

bmotik: if we move forward splitting, I think we should take everything out

<bmotik> -q

alanr: I disagree unless strong opposition. it would be a step backwards

ianh: if we resolve in favor of your approach, doesn't that mean ripping out what's there now?

alanr: ontology header is better than nothing, if we remove it we may have to readd it later

bmotik: I'd prefer to discuss if we need incompatibleWith at all

alanr: it seems we're now moving backwards

pfps: I suggest going as proposal says, discuss incompatible with as separate issue

bmotik: out of document?

pfps: minimal change to current doc. it is an interim state, even if no one likes it

bmotik: ok

<IanH> PROPOSED: resolve Issue 21 and Issue 24 Imports and Versioning, per update from Boris, Peter's email and subsequent discussion, but open new issue on status of incompatibleWith

<pfps> +1 to resolve this way

<bmotik> +1

<alanr> +1

<uli> +1

<Rinke> +1

<IanH> +1

<ivan> 0

+1

<baojie> 0

<Ratnesh> +1

<bcuencagrau> +1

<IanH> RESOLVED: resolve Issue 21 and Issue 24 Imports and Versioning, per update from Boris, Peter's email and subsequent discussion, but open new issue on status of incompatibleWith

<Zhe> +1

<alanr> happy happy

<alanr> joy joy

<bmotik> ACTION to bmotik2: Update the strucutral spec according to resolution of ISSUE 21 and ISSUE 24

<trackbot> Sorry, couldn't find user - to

<bmotik> ACTION: bmotik2 to Update the strucutral spec according to resolution of ISSUE 21 and ISSUE 24 [recorded in http://www.w3.org/2008/06/25-owl-minutes.html#action02]

<trackbot> Created ACTION-163 - Update the strucutral spec according to resolution of ISSUE 21 and ISSUE 24 [on Boris Motik - due 2008-07-02].

ISSUE-81

ianh: ISSUE-81 can be resolved using bmotik's proposal to use an alternative vocabulary for reification
... any reasons not to resolve?

<IanH> PROPOSED: resolve Issue 81 Reification of Negative Property Assertions, per Boris's email

<pfps> +1 to proceed apace

<bmotik> +1

<Rinke> +1

<IanH> +1

+1

<bcuencagrau> +1

<ivan> +1

<Ratnesh> +1

<uli> +1

<IanH> RESOLVED: resolve Issue 81 Reification of Negative Property Assertions, per Boris's email (http://lists.w3.org/Archives/Public/public-owl-wg/2008Jun/0156.html)

<alanr> +1

<ivan> happy happy

<Zhe> +1

<JeffP> +1

issue discussions

<Rinke> http://lists.w3.org/Archives/Public/public-owl-wg/2008Jun/0171.html

ianh: brief revisit of profile naming (ISSUE-108)
... (as in Carsten's email) at least OWL-R and OWL-EL names are ok, DL-Lite needs a name
... Carsten proposed calling it owl-db, but that's likely to be contentious

<Zhe> :_

msmith: why can't we call it dl-lite?

<calvanese> unmute me

<calvanese> unmute me

<alanr> we want to market to a larger community!!

ianh: owl-lite is deprecated, owl dl-lite seems rather long winded

<sandro> "OWL2 Lite" ?

<alanr> OWL-D

calvanese: we believe name owl-db would be suitable, since owl-r people like owl-r lets use owl-db
... owl-d doesn't evoke anything related to dl-lite

<alanr> OWL-I

calvanese: I am not in favor of owl-d

zhe: is this profile specific for db modeling integration and nothing else?
... owl-db name implies something

<alanr> quantify "large"?

calvanese: profile was created to connect to large databases. we believe it is specifically suited to databases

<alanr> millions, 100s of millions?

<alanr> 10s of billions?

calvanese: also conceptually matches expressivity of databases

zhe: misleading to me because dl-lite can be provided to other domains
... plus gives users belief dedicated to storing owl
... gives impression only implementable with db, nothing else
... dl-lite could apply to sparql endpoint as well

calvanese: one point is that its implemented using database technologies

zhe: is this implementation specific?

calvanese: its how the profile came about
... its tuned to these features

ianh: useful exchange, and what we suspected. owl-db is controversial. any other less controversial names?

<Rinke> Profile names are easily interpreted as denoting disjoint `features'

bmotik: why not 1,2,3 or A,B,C?

<alanr> the only reasonable mnemonic is "R"

ianh: we have reasonable names for EL++ and OWL-R which people are comfortable with. isn't 1,2,3 silly?

bmotik: what's wrong with current names?

ianh: owl dl-lite is too much of a mouthful

alanr: only name with good pneumonic is OWL-R, EL++ is historical and only relevant to small audience

<sandro> +1 get away from history.

alanr: I support getting away from historical names and suggest 1 letter (fairly meaningless) names

<alanr> yes, peter, but for how many others?

<sandro> "DL" is another bad name.

bmotik: owl dl-lite is too much of a mouthful, what about just dl-lite

<alanr> I agree, that DL is another bad name

bmotik: el++ has established itself, it doesn't need the owl prefix

ianh: that may be a step too far

<alanr> OWL-C for OWL-DL (OWL-Complete)

<alanr> OWL-A for (OWL-Anything for OWL-Full)

<Zakim> sandro, you wanted to propose leaving this to marketing

<Rinke> DL-Lite: about assertions, why not OWL-A

sandro: we are worst people to pick names. someone should subject a marketing department to this not us
... knowledge of history is an impediment

ianh: another side, the marketing people ask you to explain because they know nothing. so, names they create will depend on who explains them

<Rinke> agree with Sandro, one complaint that came up in my little survey was that people didn't know what the names meant

<ivan> +1 to Rinke

sandro: names should be targeted at people making the purchase decision

calvanese: name is indication, choice will be made on features

<alanr> I was convinced

calvanese: I made several good arguments for why owl-db is good for dl-lite
... I didn't hear compelling, non-marketing counterarguments

zhe: why not call owl-r owl-db? oracle is largest database in the world and implements owl-r?

<JeffP> We can call it OWL-Aberdeen

<ivan> JeffP: I would prefer OWL-Amsterdam!

<JeffP> hehe

<Rinke> me too!

ianh: enough of this discussion. owl-db is just too attractive, so probably no one can have it

<sandro> +1 to random city names. :-)

<ivan> rowl, dowl?

<Rinke> howl?

<alanr> who gets OWL-Bagdad?

issue-67 reification

UNKNOWN_SPEAKER: anyone?

pfps: I don't think anything needs to be done, current status is fine

ianh: current status is that we're using rdf reification

alanr: I'm happy with current reification

<Zhe> second alanr

alanr: as long as triple being reified is included

bmotik: I don't think we should output triple being reified
... this can be handled in the semantics

<alanr> that's not an argument against. It's an argument that says we can also do it a different way

zhe: conceptually, bmotik is 100% correct. but with tons of annotations this makes implementers life difficult
... what's the objection to adding the triple

alanr: yes, what's argument against? this is a divergence from rdf semantics

<alanr> I put a proposal for how to solve this on the email

bmotik: impossible to know when mapping rdf to ontology if ontology contained axiom or just annotation of axiom
... I consider sticking with current better solution

+1 to supporting annotation of non-present axioms

<alanr> There is also rdf/xml support for concise reification when it includes the triple

pfps: I don't believe argument that additional processing burden is accurate since it introduces an additional triple to parse

zhe: bmotik, I believe you proposed solutions via email to some of these problems.
... pfps, oracle believes not including triple will make life harder

<bmotik> +q to respont to Zhe

alanr: support for concise reification in RDF/XML, but only in some circumstances

<sandro> (er, no, you still need to parse the triples even when not using the RDF/XML trick.)

bmotik: are you proposing we use this special syntax

alanr: if triple is in serialization, on can put an id on the predicate to indicate reification
... there is no shorthand for only the reified part

ianh: closing discussion soon

<Zakim> bmotik, you wanted to respont to Zhe

<alanr> no bad ida

<alanr> better to add a special annotation so they are parallel

<alanr> I don't understand

<ivan> me neither

bmotik: one could use following procedure.... if re-ified and non-reified version are present... but this is non-monotonic. question to zhe - if hint that reified triples in RDF/XML should use this shorthand, would that be ok?

<ivan> I do not think we can do that, Boris

<Zhe> sounds good

ianh: take to email, then revisit discussion

general discussion, schedule

ianh: agenda has short list of things needing attention
... features: 1) rich annotations, 2) nary datatypes

<uli> Bijan isn't here

ianh: no bijan? :( perhaps uli on nary?

uli: what are you after?

ianh: I'd like some comments on schedule?

uli: we could be moving really faster. I won't be around for next two weeks, otherwise I'd say proposal in 1 week

ianh: a concrete proposal for what should be added to spec?
... but not now?

<alanr> probably depends on what happens next week and the week after too...

uli: depends on this week.

ianh: this is reasonable guesstimate

alanr: we should get quick check-in on prioritizing things. rich annotations, nary
... how are people on nary? priorities, benefits vs cost of delaying?
... when do we say it's out?

ianh: is my answer some number of weeks?

<bmotik> -q

<bmotik> +q

alanr: I would like to hear from people. I'd like to hear input.

ianh: is it significant delay worthy?

msmith: I think nary are important and would be prepared to wait some

<uli> "How horrible would you think failing on n-ary be?"

<pfps> i'm prepared to wait forever as long as it isn't more than 15 minutes (thanks Oscar Wilde)

<bmotik> I believe that n-ary datatypes are a high-risk feature

<Achille> we can leave without nary

<alanr> I'm concerned about unknowns with n-aries, and known issues, like difficulty in combinations.

bmotik: adding nary adds a huge burden to developers. some algorithmic issues haven't been resolved and I'm skeptical

msmith: notes Carsten also absent

<uli> good point

<Achille> it is not worth delaying the spec for it

ianh: not time now to get to into the details

<ivan> owl3?

uli: not having any nary support would be regretted later as something we missed

ianh: perhaps we should set some implementation bar
... 2 implementations to get to rec, correct?

sandro: in general, should only add things for which we think reasonable to there may be two implementations

<pfps> +1 to "at risk"iness

sandro: if we're unsure, that means its at risk

alanr: that doesn't help because there's significant work to get it into the spec

ianh: i agree with that, but the implementation point clarifies just how much expressive power we want to add.

<Zakim> alanr, you wanted to give one more thought

ianh: those wanting it very powerful must weight that against cost of implementing it so that it can proceed

<bmotik> +q

alanr: so far focused on one type of concrete domain extension, < > simple arithmetic

<uli> alanr, can you explain this?

alanr: perhaps allen interval relations instead. I'm taking this up with carsten

<alanr> uli, yes, via email

bmotik: allen interval for time intervals will not solve problems for owl

<alanr> won't solve all time problems for time. But may solve some some time problems

bmotik: nary datatypes won't help this ...
... (scribe interpret) because they only apply to data properties on a single individuals (not comparison between multiple events)

ianh: will ask bijan next week about this
... also discussion about datatypes in general, what should be supported. is this going to derail us?

<bmotik> +q

bmotik: thinks we can resolve. we have to resolve

<alanr> I have concerns that this will take time.

bmotik: I don't think solution is difficult

<uli> ;)

<uli> yes

<uli> very

ianh: ISSUE-118 is languishing
... any champion for this issue?

alanr: I've suggested unnamed and bnodes as alternative constructs

ianh: documents need to be produced. test, ufds

<alanr> ACTION: alan to send email re: suggestions (again) for unnamed individuals *in addition* to bnodes [recorded in http://www.w3.org/2008/06/25-owl-minutes.html#action03]

<trackbot> Created ACTION-164 - Send email re: suggestions (again) for unnamed individuals *in addition* to bnodes [on Alan Ruttenberg - due 2008-07-02].

<alanr> mike, you know about action=raw ? to get raw mediawiki pages?

alanr, no. thanks

msmith: re tests, I'm targeting f2f3 as a milestone. two parts, the tests, and the documents
... I'll try to get something to the group before f2f3 on each

<alanr> mike, see http://svn.neurocommons.org/svn/trunk/product/wiki/get-ncpage-ontology.pl

ianh: none for ufd

pfps: I think bijan is working on primer

additional business

<JeffP> bye

<ivan> bye

ianh: no additional business, adjourn

<Zhe> thanks

<uli> bye bye

<Ratnesh> bye

<sandro> msmith, I put some notes about scribing here: http://www.w3.org/2007/OWL/wiki/Scribe_Conventions#After_scribing_.28New_Style_Minutes.29

<IanH> I'm hoping that Turkey wins on penalties :-)

<alanr> e.g http://sw.neurocommons.org/cgi-bin/get-ncpage-ontology.pl?page=CommonsPurl:Record/Ncbi_gene&section=purlRdf

<uli> I hope that they have great game

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/cerned/concerned/
Found ScribeNick: msmith
Inferring Scribes: msmith

WARNING: Replacing list of attendees.
Old list: Peter_Patel-Schneider +1.202.408.aabb +0186527aacc Ivan Sandro Ratnesh Zhe msmith +1.518.276.aadd baojie bmotik IanH uli +0122427aaee Achille JeffP bcuencagrau Alan calvanese Rinke
New list: Peter_Patel-Schneider +1.202.408.aabb +0186527aacc Ivan Sandro Ratnesh Zhe msmith +1.518.276.aadd baojie bmotik IanH uli

Default Present: Peter_Patel-Schneider, +1.202.408.aabb, +0186527aacc, Ivan, Sandro, Ratnesh, Zhe, msmith, +1.518.276.aadd, baojie, bmotik, IanH, uli
Present: Peter_Patel-Schneider +1.202.408.aabb +0186527aacc Ivan Sandro Ratnesh Zhe msmith +1.518.276.aadd baojie bmotik IanH uli

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

Agenda: http://www.w3.org/2007/OWL/wiki/Teleconference.2008.06.25/Agenda

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

Got date from IRC log name: 25 Jun 2008
Guessing minutes URL: http://www.w3.org/2008/06/25-owl-minutes.html
People with action items: alan bmotik2 calvanese