From OWL
Jump to: navigation, search

These minutes have been approved by the Working Group and are now protected from editing. (See IRC log of approval discussion.)

See also: IRC log

(Scribe changed to Rinke Hoekstra)


Roll Call

Agenda Amendments

Alan Ruttenberg: any amendments?

Peter Patel-Schneider: what about the recent message sent out about next week?

Next Week's TC

Alan Ruttenberg: next week's TC cancelled, no chairs, DL workshop

Alan Ruttenberg: any objections?

Peter Patel-Schneider: presumably Zakim would be available


Alan Ruttenberg: F2F3 in Boston on july 28 and 29

Alan Ruttenberg:

Alan Ruttenberg: please put yourself on the list if you're planning to attend or not

Previous Minutes

Alan Ruttenberg: needed some cleanup, heard from peter

Ian Horrocks: I did some work on them

PROPOSED: accept previous minutes

Peter Patel-Schneider: depends on whether jeremy is happy
Sandro Hawke: +0
Peter Patel-Schneider: ~0
Ian Horrocks: +1
Boris Motik: +1
Rinke Hoekstra: +1
Uli Sattler: +1
Alan Ruttenberg: +1
Ivan Herman: +1
Michael Smith: +1 to accept minutes
Bernardo Cuenca Grau: +1
Evan Wallace: +0 (wasn't present)

RESOLVED: accept previous minutes

Jeremy Carroll: +0
Jie Bao: 0

Alan Ruttenberg: As Bijan recently said, if you weren't there you're actually a very good reviewer of the minutes: should be comprehensible

Pending Review Actions

Action 131

Alan Ruttenberg: implement decisions from the F2F2 for RDF mapping in particular

Alan Ruttenberg: has obviously been done

Alan Ruttenberg: solicit some reviewers to see whether this has been done (implementers, and someone involved in OWL Full)

Alan Ruttenberg: Michael? would you be willing to review

Michael Schneider: well, hmm, ok, yes..

Alan Ruttenberg: have the potential to affect owl full

Sandro Hawke: would it be helpful to create a colour-coded diff

Boris Motik: Don't really bother with a diff: it will be useless.

Michael Schneider: differences are quite big

Michael Schneider: will simply read it

Alan Ruttenberg: Achille are you willing to take this on?

Achille Fokoue: won't be able to do this in the next two weeks

Alan Ruttenberg: that's no problem

Alan Ruttenberg: do you want to do this, and if so before when would you be able to do this?

Achille Fokoue: maybe end of may?

Alan Ruttenberg: would be happy personally, if you're willing

Bijan Parsia: Do we have publication goals?

Sandro Hawke: will action Achille and Michael

Sandro Hawke: all documents? or parts? due date?

ACTION: schneider to review the changes made as result of Action 131 due May 20

trackbot-ng: Created Action 147 - Review the changes made as result of Action 131 due May 20 [on Michael Schneider - due 2008-05-14].

ACTION: achille to review the changes made as result of Action 131 due May 30

trackbot-ng: Created Action 148 - Review the changes made as result of Action 131 due May 30 [on Achille Fokoue - due 2008-05-14].

Action 133

Alan Ruttenberg: is actually related, and the review would include that action as well

Alan Ruttenberg: if anyone disagrees that these actions aren't done, speak up

Action 132 and Action 129

Bijan Parsia:
Bijan Parsia:

Alan Ruttenberg: you laid out the possible options, do you have any particular idea about this, bijan?

Bijan Parsia: I didn't think that would be part of the action

Alan Ruttenberg: what we should do at least is ask if people could respond to vent their ideas/opinions to the options listed by bijan

Peter Patel-Schneider: how to effect the request?

Bijan Parsia: didn't feel like iterating all examples, if someone feels like adding examples, please do!

Due and Overdue Actions

Action 42

Action 43

Alan Ruttenberg: any update about this from jeremy, bijan, sandro?

Bijan Parsia: I wait upon a solution

Sandro Hawke: no progress, willing to work on this, can't get it to the top of my queue

Alan Ruttenberg: if anyone has test cases, please add them to the wiki

Bijan Parsia: if anyone could point me to a preferred format for this

Action 136

Alan Ruttenberg: jeremy?

Jeremy Carroll: don't know how much time is needed to discuss this, for next week is within the RIF timescale

Alan Ruttenberg: no meeting next week

Jeremy Carroll: any chance to fit 5 minutes in today?

Alan Ruttenberg: I'll put it in as the first issue

Peter Patel-Schneider: remember to refresh :-)

Action 142

Bijan Parsia: Peter finished it before I could start

Alan Ruttenberg: taken over by proposals from peter

Alan Ruttenberg: let's close that

Action 145

Alan Ruttenberg: Jeremy?

Jeremy Carroll: forgot this

Action 146

Jeremy Carroll: working on this

Action 144

Jeremy Carroll: this one has slipped my mind, and I am unlikely to push this forward

Alan Ruttenberg: does the current proposal satisfy our need in this area

Action 143

Alan Ruttenberg: didn't get to that

Bijan Parsia:

Bijan Parsia: one question about this last question

Bijan Parsia: OWL Lite was intended to be similar to EL++, DL Lite, or OWL-R but there were several problems with its design, most notably that it was not significantly easier to implement nor more robustly scalable than OWL DL. Thus, there wasn't a huge performance (or tool) benefit to staying inside OWL Lite. OWL Lite also could express things that were in OWL DL but in very indirect ways that were very surprising. For example, while the "complementOf" construct was not part of
Bijan Parsia: OWL Lite is a subset of OWL DL 2 and OWL Full 2 but is no longer a recommended profile.

Bijan Parsia: I thought I sent this email, I already have some text about the old species in the primer. I just put a pointer to it

Alan Ruttenberg: thought was that the particular wording that jeremy had was quite nice

Alan Ruttenberg: if you think you have covered it, communicate this to jeremy

Alan Ruttenberg: I'll put an editorial note to put in the text that he had, so you can see whether you feel that adequately covers it

Jeremy Carroll:

Review of RIF Compatibility

Jeremy Carroll: email linked from yesterday, mentioned a very few points. One point I forgot to put in the email

Ian Horrocks: Scribe assist: Jeremy said: 118N guys don't know much about SW; rely on him to advise; he believes that they will be happy with our current position (dealing with literals)

Jeremy Carroll: they use a generalised graphs ..something ..something ..bnodes ..literals

Jeremy Carroll: an RDF graph a subject is a bnode or uri, a predicate which is a uri, an obect which is a uri or literal

Ivan Herman: sparql dropped that!

Jeremy Carroll: in their design they allow all three types in all three positions. This is a generalisation and quite an improvement, if you ask me

Alan Ruttenberg: any impact on serialisation?

Jeremy Carroll: it works with RDF graphs, it might mean that you can have a conclusion in RIF that can't be serialised

<! --
Peter Patel-Schneider: wait
Bijan Parsia: Dropped what?

Peter Patel-Schneider: can we do this too?

Sandro Hawke: +1 Peter

Jeremy Carroll: allright by me

Michael Schneider: if we allow generilized graphs, then we can have anonymous inverses directly mapped to RDF :)

Peter Patel-Schneider: surprised that alan isn't jumping up and down and screaming

Peter Patel-Schneider: destroys serialisability of everything

Bijan Parsia: I'll note that Alan is among the public, so can comment
Sandro Hawke: Peter: I'd like OWL to do this too -- to use generalized RDF graphs.
Peter Patel-Schneider: Well, actually, "go outside of RDF" - generalized RDF graphs are too limiting.
Alan Ruttenberg: IIRC they don't have an RDF serialization at all

Jeremy Carroll: at the end of the email, they have text about OWL2 that could be more neutral

Jeremy Carroll: about punning

Jeremy Carroll: I would suggest that this WG should make that comment, it's not for me to say that by myself

Jeremy Carroll: the minimal review is that comment, along with some text like (...)

Jeremy Carroll: a very minor point, is that they haven't decided what sorts of entailments to include for RDF

Jeremy Carroll: simple entailment, rdf entailment, rdfs entailment

Michael Schneider: I think the problem is that you cannot represent predicate bNodes in RDF/XML (?)

Jeremy Carroll: should say, don't bother thinking about RDF entailments

Bijan Parsia: q+ to ask about presentation syntax

Jeremy Carroll: bulk of my comment is about a very silly thing actually... syntax is not standard

Peter Patel-Schneider: q+ to mention that this has already been raised to the RIF WG

Jeremy Carroll: we might want to have some minor supportive text from the WG

Zakim: pfps, you wanted to mention that this has already been raised to the RIF WG

Peter Patel-Schneider: comment about the inscrutable syntax choices has been pointed out to them several times

Peter Patel-Schneider: without much success

Evan Wallace: +1 on complaining as a wg about the ^^ syntax
Zakim: bijan, you wanted to ask about presentation syntax

Bijan Parsia: I understand this to be part of the presentation syntax

Sandro Hawke: yes

Bijan Parsia: since it doesn't hit the wire, I don't care too much

Bijan Parsia: it's unclear whether our WG should care too much, unless we want to synchronise our spec. styles

Ian Horrocks: I'm inclined to agree with Bijan on this

Ivan Herman: it may affect one point. If we want to harmonise on the profile, we will be forced to take over that syntax in our description and pay the price

Sandro Hawke: I strongly disagree

Sandro Hawke: there's no grammar, you are not allowed to parse this syntax, it just helps to explain the semantics

Bijan Parsia: Though they claim that's not a writeable syntax, people always parse it

Alan Ruttenberg: AS was parsed in OWL 1

Sandro Hawke: WG said you shouldn't

Alan Ruttenberg: is his specified as such?

Sandro Hawke: yes

(.. something about the way in which RIF deals with internationalised strings, rif:iri)

Jeremy Carroll: Sandro was arguing against including a comment on this topic (deviation from norms in presentation syntax)

Sandro Hawke: agnostic

Jeremy Carroll: many people have raised this, and it hasn't been taken notice of does suggest that it should be taken up as a WG issue

Peter Patel-Schneider: q+ to note that rdf:iri shows up in the RIF XML syntax

Jeremy Carroll: each WG has a task to take notice of other WG's

Bijan Parsia: just to go back to ivan's point. I agree that it is not to be serialised. We do have an interest, it is generally good to have the specs harmonised: some harmony is beneficial to reader

Bijan Parsia: it's still not a WG issue, jeremy is free to raise a last call issue

Sandro Hawke: Yeah -- it might make sense to have OWL and RIF rationalize their Presentation Syntaxes.

Bijan Parsia: we should focus on things that really impact our work

Bijan Parsia: not on just 'icky' stuff

Alan Ruttenberg: there's no show stoppers here. 1) don't waste your time on rdf 2) presentation syntax isn't standard

Alan Ruttenberg: we could send a note saying that we think you have done a good job etc. etc.

Alan Ruttenberg: reading both specs shouldn't be confusing, it would help to have a common syntax for readability reasons

Peter Patel-Schneider: shows the syntax
Zakim: pfps, you wanted to note that rdf:iri shows up in the RIF XML syntax

Alan Ruttenberg: just show our interest on this issue, but no requirement

Peter Patel-Schneider: the syntax is not just in the presentation but also in the RIF-BLD

Sandro Hawke: I'm not sure what to make of that

Alan Ruttenberg: it's beyond presentation syntax

Sandro Hawke: I don't know what the concern is in RIF-BLD

Sandro Hawke: don't know if there's a problem with rif:iri

Sandro Hawke: my understanding is that RIF does not use IRIs as symbols (As owl and rdf). Instead it has a data mapping to go from IRIs to the arbitrary resources they stand for

Sandro Hawke: esp. michael kiefer preferred to do it like this

Alan Ruttenberg: do you think that's something we should be commenting on?

Peter Patel-Schneider: that's a good question... if we wanna fight, sure... but expect to fight

Alan Ruttenberg: my proposal is that we don't wan to fight, but say very clearly what we feel, and go on the record. Without saying that they *have* to fix the issue in the way we propose

Alan Ruttenberg: if peter doesn't mind writing up the note (removing jeremy's irritation etc.)

Peter Patel-Schneider: i don't have any idea of what should be said in a communication to the RIF WG
Zakim: sandro, you wanted to ask how much effort / delay OWL-WG would be willing to tollerate on unifying Presentation Syntaxes?
Ian Horrocks: I'm not sure if I can promise to remove Jeremy's irritation ;-)
Jeremy Carroll: "We request one change concerning description of OWL2 and have two other comments RDF entailment & presentation syntax"

Sandro Hawke: one other comment, if you can say where it's actually harmful that would be good. If you want to have them change it, you should be clear on how much you would want this WG (owl) to slow down

Bijan Parsia: But then that's a jeremy comment and not an OWLWG comment

Jeremy Carroll: it's not about RIF and OWL but about the specs that are already out there!

Evan Wallace: Do we care about Jeremy's item 17 (text about OWL 2 and punning)?

Alan Ruttenberg: How about a strawpoll, action a couple of people simply to write up some documentation in a neutral tone about what we saw and what we thought

Sandro Hawke: +1 to alan's proposal
Ivan Herman: +1

Jeremy Carroll: we'll go on to the straw poll

Jeremy Carroll: +1
Achille Fokoue: +1


Evan Wallace: +1
Peter Patel-Schneider: ~0

Rinke Hoekstra: +1

Markus Krötzsch: 0
Bernardo Cuenca Grau: 0
Uli Sattler: 0
Michael Schneider: +epsilon (I still need more information on this)
Martin Dzbor: 0
Michael Smith: 0
Bijan Parsia: +1 to any response...I certainly wouldn't block arbitrary complaints to some other working group :)

Alan Ruttenberg: neutral and positive mix...

Alan Ruttenberg: keep this action open?

Jeremy Carroll: yes

Ivan Herman: we did not officially approve jeremy's last point as a comment to the RIF group and the text they use regarding owl 2

Alan Ruttenberg: my idea was that the action would address this, and we would have some text that we could approve

Jeremy Carroll: perhaps approve on a draft via email, and send this draft before the deadline, vote on this post hoc, on the next telecon

Michael Schneider: why do we only have /one/ week?
Jeremy Carroll: RIF's timeline includes deciding whether they are ready for last call or not soon


Alan Ruttenberg: 15 minutes max

Alan Ruttenberg: on issues

Issue 85

Alan Ruttenberg: proposed to close as postponed, better use a better annotation syntax

Alan Ruttenberg: Alan Rector, who is the champion on this, was fine to postpone

Alan Ruttenberg: any questions abbout Issue 85

PROPOSED: to resolve Issue 85 as per

Peter Patel-Schneider: +1 .................. (waiting for the proposal)
Boris Motik: +1
Alan Ruttenberg: +1
Jeremy Carroll: 0
Bijan Parsia: +1
Ian Horrocks: +1
Ivan Herman: 0
Uli Sattler: +1
Rinke Hoekstra: +1
Evan Wallace: 0
Martin Dzbor: +1
Markus Krötzsch: +1
Sandro Hawke: 0
Michael Smith: +1
Jeremy Carroll: 0 (haven't been following this one)
Bernardo Cuenca Grau: +1
Achille Fokoue: 0

RESOLVED: to resolve Issue 85 as per

Michael Schneider: still RIF - wouldn't this be something for after last call? then they believe they are fine, and ask others for input

Issue 97

Alan Ruttenberg: question of whether or not the actual XSLT transformation is needed to be there, or whether the GRDDL could simply point to the mapping

Bijan Parsia:

Alan Ruttenberg: trick that I proposed does not actually work, as GRDDL does require an XSLT

Bijan Parsia: As noted above, each GRDDL transformation specifies a transformation property, a function from XPath document nodes to RDF graphs. This function need not be total; it may have a domain smaller than all XML document nodes. For example, use of xsl:message with terminate="yes" may be used to signal that the input is outside the domain of the transformation.
Bijan Parsia: Developers of transformations should make available representations in widely-supported formats. XSLT version 1[XSLT1] is the format most widely supported by GRDDL-aware agents as of this writing, though though XSLT2[XSLT2] deployment is increasing. While technically Javascript, C, or virtually any other programming language may be used to express transformations for GRDDL, XSLT is specifically designed to express XML to XML transformations and has some good safety c

Bijan Parsia: If I look at the GRDLL document it does not specify that you have to have an XSLT, it just mentions that you should have a transformation

Bijan Parsia: I would just like to have some textual support for your claim

Ivan Herman: bijan is right in terms of the recommendation. In fact, the GRDDL spec does not require the XSLT. However, as far as I know, no GRDDL implementation at the moment can handle anything else but XSLT...

Sandro Hawke: can't hear Ivan very well --- distant echos or something.
Sandro Hawke: (Ivan, it sounds like you're in a cathedral)
Bijan Parsia: See for why having specced retrievable things is a bad idea

Alan Ruttenberg: one of the objections to doing this was that we would have two normative rdf mappings. What we thought we could do is to assign an action to someone who would be happy to create an XSLT, and only publish it as a note of the wg

Alan Ruttenberg: would avoid any confusion about the status, and be friendly to anyone who would like to use that technology

Bijan Parsia: bad idea that the WG does implementation (especially as there are competing implementations such as the OWL API)

Bijan Parsia: best practice is to include it in your own software

Bijan Parsia:

Ian Horrocks: I find bijan's arguments quite persuasive on this. If it's not actually part of the GRDDL spec, I'm not sure why we're doing it

Ian Horrocks: I'm not quite sure what would be the note... algorithm? transformation?

Bijan Parsia: I'm fine with us having pointers to implementations

Peter Patel-Schneider: there is a competing specification of the transformation ... the one we're writing

Jeremy Carroll: I wanted to take issue with bijan on the web retrievable issue. If you do object to this, you should have made an objection to the GRDDL spec. As it's actually a recommendation, there is a reason to take note of this

Bijan Parsia: It's still expensive for the w3c
Bijan Parsia: It's still expensive for the client

Jeremy Carroll: we can rely on the W3C of things not going away

Jeremy Carroll: point to TWO GRDDL transforms -- one in XSLT (informative), one being the english spec (normative). It would be clear and helpful. [Scribe assist by Sandro Hawke]

Jeremy Carroll: my proposal would be that we could have two links, one to the actual spec (normative) and the xslt which is not normative (with a note on the top)

Alan Ruttenberg: chair hat off

(Ian Horrocks takes over as chair)

Alan Ruttenberg: I relate my understanding of what the point of this is

Alan Ruttenberg: same understanding as Jeremy's.

Alan Ruttenberg: the intention is that the XSLT is published, cached and then used to actually transform stuff to rdf/xml from xml. The spirit of this is that we put an XSLT transform there

Uli Sattler: ...this is about why we want an XSLT transform

Alan Ruttenberg: do not think it's damaging, do not think it should be blocked

Alan Ruttenberg: one of my objections to OWL/XML was resolved by adopting GRDDL

Bijan Parsia: My worry about adding grddl was assuage by my reading of the recommendation which ensured that we didnt' ahve to supply xslt!
Jeremy Carroll: +1 to Alan - just pointing to the Mapping doc would not address my concerns about OWL/XML

Alan Ruttenberg: and if we're not staying in the spirit of this, then I question whether we want the OWL/XML syntax

Alan Ruttenberg: continue next week?

Bijan Parsia: I would have objected to the grddl requirement if I knew there was secret extra-recommendation requirements!

Bijan Parsia: I don't see anything in the GRDDL spec that says that you have to retrieve something from the web

Alan Ruttenberg: If we're not going to support GRDDL in the live-on-the-web spirit, then that's new information, and I might object to having the XML format for OWL. [Scribe assist by Sandro Hawke]

Bijan Parsia: I see the value of a web-retrievable transformation. We are not in that circumstance where we need that

Bijan Parsia: do people objecting to OWL/XML prefer to get some transformation somewhere from the web? I don't think this is a starter

Ian Horrocks: defer this until next week

Sandro Hawke: quick show of hands if anyone seconds Bijan's perspective?

Bijan Parsia: and the reason i didn't give a formal objection to GRDDL was because I had no idea that it would be read this way!

Sandro Hawke: Should we have a strawpoll about retrievable but non-normative XSLT?

Alan Ruttenberg: note=actual transform
Alan Ruttenberg: if there is a note

Ian Horrocks: is this about publishing a note, or is the note a uri that points to it, or describes it

Bijan Parsia: In fact, people can add their own grddl property to *thier* owl/xml that points to whichever transformation function they want?

PROPOSED: JJC's proposal for non-normative

Jeremy Carroll: suggestion: strawpoll that we have retievable and non-normative XSLT pointed to from OWL/XML namespace

Jeremy Carroll: in the OWL/RDF there's a bit of code that points to a GRDDL transform

Alan Ruttenberg: don't have time for this (chair hat on)

General Discussion: Imports

Alan Ruttenberg: Peter's updated proposal, Boris' comments on this

Alan Ruttenberg: didn't grab this from the web

Peter Patel-Schneider: latest proposal is to publish by location, do versioning by publishing in multiple spots. Implement this by writing this in section 3 of the syntax document

Peter Patel-Schneider: import by location; multiple versions = multiple locations; .... [Scribe assist by Sandro Hawke]

Boris Motik: the idea is to somehow split the imports from the actual locations where the ontologies are published

Boris Motik: question is, where is an ontology actually located?

Boris Motik: an ontology can have an ontology uri, and optionally a versioning uri. If it has any of these uris it should be published at a location that is equal to either one of these uri's

Boris Motik: imports points to a particular location, this location can be either equal to the ontology uri or the version uri that you want to import

Boris Motik: this procedure can be overridden for the purposes of caching

Sandro Hawke: pretty clear

Alan Ruttenberg: any questions from anybody?

Jeremy Carroll: +1 it's very elegant
Boris Motik:

Alan Ruttenberg: have you thought about forward moving, if we decide to have something more involved as regards version information, does this preclude that?

Boris Motik: no, don't think so. You can actually encode additional information in the uri

Boris Motik: this is completely orthogonal.. you could abstract the whole thing by saying that you need some way of comparing two version uri's.

Boris Motik: you could encode numerical information and do comparison etc.

Uli Sattler: I was wondering in a similar direction

Uli Sattler: this mechanism would also allow me to always retrieve the latest version?

Boris Motik: the latest version is always at the location of the ontology uri

Boris Motik: when you create a next version, this current version goes somewhere else, and the new version gets put at the location

Uli Sattler: lovely

Boris Motik: if you want to import the latest version, you just point to the ontology uri.

Jeremy Carroll: this is very simple to spec, excellent, strong support

Sandro Hawke: q+ to ask if you can have a updated-version version-URI (latest in the 4.x series, latest in the 5.x series) ?

Alan Ruttenberg: it is still my intention to write a note offering this more complicated thing that shows that the simple mechanism doesn't handle this. Could we keep an issue open explaining use cases that I have, just to say that there's still an issue here

Sandro Hawke: and to ask about override / caching.....
Zakim: sandro, you wanted to ask if you can have a updated-version version-URI (latest in the 4.x series, latest in the 5.x series) ?

Alan Ruttenberg: easy to get out of sync in the OBO

Alan Ruttenberg: currently no way to repair that

Uli Sattler: ...but this would require a version-naming scheme?

Sandro Hawke: have you thought of mechanisms where you would have double version mechanisms, i.e. latest in 4.x latest in 5.x

Sandro Hawke: main production releases, beta releases, major / minor releases (latest of some obsolete version etc.)

Peter Patel-Schneider: if you have multiple version URIs, something along these lines can be done
Uli Sattler: I think that this proposal was oblivious to how versions are numbered/named

Boris Motik: multiple ontology uri's, multiple default locations... this could be added, but in the existing proposal this is not captured

Jeremy Carroll: That can be done with this: latest, versionInfo = latest4, versionInfo = latest4.2 versionInfo = latest4.3
Zakim: pfps, you wanted to talk about WG process

Peter Patel-Schneider: a previous version allows for multiple version uris, which I think would allow multiple branching, slightly more complex... don't know whether it's worthwhile allowing this

Peter Patel-Schneider: the WG decides things, and then people give in or object. What is this thing about having a minority report?

Ian Horrocks: Very hard to hear now!
Ian Horrocks: Better!

Jeremy Carroll: I'm pretty sure that sandro's use case is covered by this. I'm happy to take up an action to describe multiple versioning using this scheme

Sandro Hawke: to recast what I think Alan was wanting to do, was say: let's go ahead with something like this, but have some text in the spec or issues list that explains to people who wants something they need, that we don't provide. This can be consensus text

Jeremy Carroll: a postponed issue would be acceptable to me

Peter Patel-Schneider: I thought I heard something about a separate note about this particular issue

Jeremy Carroll: q+ to mention more capability

Alan Ruttenberg: what I was saying was that having something more stronger is not something we have consensus about, but we could have something in a note that describes a more elaborate scheme

Alan Ruttenberg: didn't think this was controversial

Alan Ruttenberg: as sandro said, we could have some text about this, that could be taken up

Alan Ruttenberg: Good idea to document what this mechanism does NOT support. [Scribe assist by Sandro Hawke]

Boris Motik: add a section about this, something similar to the 'oh, you could override the location in some way'

Boris Motik: gives people an idea on how to use this versioning. We could easily capture what should or could be added... what tools might want to do with this

Boris Motik: once we see what this looks like, it might be easier to comment on this. Unless anyone really objects, we could put this into the spec, and see how people feel about this

Zakim: JeremyCarroll, you wanted to mention more capability
Ian Horrocks: OWL 3 -- nooooooooooo!

Jeremy Carroll: OWL2 is an improvement on OWL1 and that's the basic idea. OWL2 imports+versioning is an improvement on OWL1, but OWL3 will (hopefully) be an improvement on OWL2

Alan Ruttenberg: seems that this proposal is as far as the normative spec goes

Alan Ruttenberg: what I'm suggesting is that there's some work that has been done about use cases.. would be nice to have a record of this

Alan Ruttenberg: like what boris is saying.

Sandro Hawke: OWL3, coming soon to a theater near you.

Alan Ruttenberg: if I have time for a note, then we could discuss this at a later point

Michael Schneider: why have a normative part about this? Why not define the imports just as the imports closure

Michael Schneider: and just leave out the files stuff

Boris Motik: we actually started from that position. The member submission said exactly that... quite a few people objected. Are we prepared to backpaddle?

Sandro Hawke: (I think Normative is important.)

Alan Ruttenberg: strawpoll about this? General feeling about this proposal is that it's a positive step forward

STAWPOLL: are people comfortable having Boris put in the changes that he suggested?

Bijan Parsia: +1 to normative
Alan Ruttenberg: +1
Rinke Hoekstra: +1
Michael Smith: +1
Michael Schneider: +1 on informative, -0.5 on normative (really my own opinion)
Sandro Hawke: +1
Ian Horrocks: +1
Markus Krötzsch: +1
Uli Sattler: +1 to the lovely proposal
Bijan Parsia: +1
Peter Patel-Schneider: +1 (surprise)
Boris Motik: +1 (unsurprisingly :-)
Achille Fokoue: +1
Evan Wallace: 0
Ivan Herman: +1; I wonder whether having several version infos is not better than just one
Bernardo Cuenca Grau: +1
Jeremy Carroll: +1 on normative

Alan Ruttenberg: strong support for doing this

Alan Ruttenberg: put action on boris, ready to close

ACTION: bmotik2 to Implement the imports proposal as described in

trackbot-ng: Created Action 149 - Implement the imports proposal as described in [on Boris Motik - due 2008-05-14].

Alan Ruttenberg: thank you TF for putting effort on this!

Alan Ruttenberg: aob?

Boris Motik: Will need to defer this action to next week, because of the workshop

Alan Ruttenberg: UFDTF expect to have a telecon on monday

Bijan Parsia: I'm traveling on monday

Alan Ruttenberg: adjourn