Agenda
See also: IRC log
<ShaneM> remind me again why I thought this was a good idea?
<RalphS> Shane :)
<ShaneM> God's Country - but we don't like to spread that around. we have enough people here now
<RalphS> Shane :)
<ShaneM> FYI - as anticipated we got a last call objection to using scoped values in attributes (for xhtml-role). We will carefully prepare a reply that we can use when we get similar objections on RDFa
<mhausenblas> mute me
<seanb> Morning!
<seanb> We now have network in Amsterdam....
<Steven> Hi there all
<seanb> ralph -- is there some special scribing convention for f2f?
<mhausenblas> Hi Steven, good to 'see' you again ...
<Steven> Hi there Michael
<RalphS> Sean, I've generally seen scribing f2f as pretty much like scribing a telecon
<Steven> scribenick: aliman
mark: follow agenda, put discussion of future to end
guus: come back to reviews later;
first take on point, this group not decided on outcome status
for RDFa; in charter, possibility to go rec track, not a
decision yet.
... proposal from RDFa TF is to go REC track. My main concern, whether there is sufficient people to carry this through. For me, recent progress of TF and also importance of work, I'm now in favour of going rec track.
... Do we need to discuss this?
<Steven> People who are not physically in the meeting, maybe you should say who you are and what your affiliations are
tom: no comment. there are these larger issues of overlap with XHTML 2, what did we decide to do about that?
guus: we move that issue to end of discussion. it's in our charter, have to say about status, whether we move work or not.
<RalphS> [Ralph Swick, SWD staff contact]
<Steven> (There are 11 in the room)
<RalphS> [Ralph Swick, SWD staff contact, calling today from Massachusetts]
<Steven> :-)
tom: need to be specific about which deliverables on which track. WG needs to agree to bring syntax to REC track; then approve publication of syntax as WD; then look at other deliverables, use cases, test cases, then figure out what is intended process for each of those, then figure out rough schedule. If we do that, and figure out overlap with XHTML 2, then we've done our duty for RDFa today.
guus: tom says, if it's clear what goes rec track and what doesn't, then OK to go for rec track.
ben: we discussed in group. focus on important normative docs, therefore only doc which needs to go rec track is XHTML 1.1 syntax. other docs are important, give supporting information. but only normative doc is syntax.
ralph: proposal for other docs?
ben: primer will be note; test cases as supporting documentation.
<Steven> (interruption as someone enters room)
guus: I'm not going to make a point about this. happy with scheme in OWL WG, full set of docs goes rec track as one package, including test cases and guide/primer. but if TF proposes to have just syntax as REC track, don't think it will make a big difference in practice.
ivan: GRDDL published primer as
NOTE.
... depends on what TF feels is achievable in time frame ... and time frame is not long.
<RalphS> [I was going to make the same point Ivan just made; more SemWeb specs have had primers as REC but most recent chose to make primer a Note]
guus: any more discussion? [no]
propose this WG agrees RDFa to go rec track, given that syntax
doc will be rec track doc. Any objections?
... ben ralph?
ralph: I'm ok with that. My preference was, to say primer might as well be rec track too, because going to be reviewed and published in sync with syntax. but am satisfied with primer not being rec.
<benadida> +1
<mhausenblas> +1
guus: syntax doc go rec track, then at later stage another doc could become part of package. make minimal decision now. no objections.
<Simone> +1 !!!
<Steven> +1
RESOLUTION: to put RDFa syntax on rec track, other RDFa docs to W3C Note.
<edsu> :-)
guus: proposal no. 2 on table, that SWDWG approves publication of XHTML 1.1 RDFa Syntax as First Public WD.
guus: Usually have message with how comments of reviewers were handled. Let's have round with reviewers.
<RalphS> [Ed summarizing his review]
Ed: In general, don't have a lot of DTD experience, so couldn't review that part. In general, this is great stuff, glad it's going to rec. Because I'm new to some of this, the CURIE I found some confusion as to whether CURIE defined here or in another syntax doc.
guus: what is status of CURIEs in this doc? part of this doc, or outside?
<ShaneM> I think Mark can take this one
<Steven> CURIE's are defined in the spec at:
mark: pragmatic approach, CURIEs
is a concept we need elsewhere, e.g. in role document, which
went to last call last friday. So idea of something which is
qname but not qname, needed elsewhere.
... like to persuade other groups e.g. SPARQL to use CURIEs (longer term thing). In short term, confusion because hedging out bets. If CURIEs don't go further, it will be in the RDFa document. If CURIEs do advance, will refer to another document.
guus: so making sure CURIEs are not on your critical path.
<RalphS> [do SWD folks in the room understand that Mark and Steven are here representing the XHTML 2 Working Group, as part of the RDFa Task Force?]
mark: Yes, and trying to keep in sync. Section on CURIEs in RDFa has got clearer since looking at other problems (e.g. with role in XHTML 2)
<Steven> [They do now :-)]
ivan: what is realistic assumption of CURIEs becoming REC in its own right before April?
mark: what would stop it?
... in terms of document, what is says ... when we're happy with explanation of CURIEs in RDFa ... not a lot of work to do.
<RalphS> [I support the XHTML 2 plan to keep RDFa independent of a *separate* document on CURIEs]
stephen: mark summed it up. we don't want it on critical path. but this work is developing concept to usable state. good to develop here, then pull out to another spec. but if can't then doesn't matter.
guus: go for now, assume we discuss planning, but planning will be tight. for next 6 months, at least in candidate rec. how realistic? from my perspective, seems very unlikely. last call document, in two or three months, chances are almost zero.
ivan: yes, except my timing would
be tougher. my goal to have as rec before beijiing. even tho
candidate rec very short, last call still needed this
year.
... decision on CURIEs in or out is concrete. technical content in last call cannot be changed. (cannot remove section) ... so need to decide before december. I think should not do that, we should keep CURIE spec inside RDFa syntax.
steven: not a problem.
<ShaneM> I feel the CURIE rules are pretty simple, and had planned to send the CURIE spec to last call in the next few weeks. But I dont mind leaving the text in the RDFa spec. I can undertake to keep them in sync. I do it all the time.
ralph: i think ivan said what i meant to say ... challenge to keep any future separate spec consistent with RDFa. but in future version of RDFa can rip out whatever duplicates separate curie spec; but for now, work without separate curie spec.
ivan: close the door to have separate spec, pragmatically.
mark: why?
<Zakim> RalphS, you wanted to comment in case Steven doesn't clarify and to clarify non-dependency
mark: there is now one sentence which says, this may come out into separate spec. If we think CURIEs in RDFa is nailed, if we then updated separate spec, would there be any problem if we then refer to it?
ivan: CURIE doc which you put out separately, would go to a number of other groups, not semweb groups, might have different requirements, could hold up RDFa for no good reason. can only refer to docs one step behind. let's say CURIE doc is delayed, then you are stuck with RDFa.
steven: if CURIE spec is causing aggravation, cannot move RDFa forward.
ivan: RDFa cannot be REC until CURIE is proposed REC.
steven: good for RDFa, good for CURIEs.
mark: made it block which could be removed. works both ways.
ben: follow mark's lead on this, sounds good.
ralph: importatn to decouple these. could include in status of doc, section which says "if curie languag of following section is published separately, intent is that this section will cite that". Ivan made crucial point, if separate specification is dependent, has to be close to end of recommendation. we need to decouple them. easy for us to find language for proposed edited recommendation for RDFa to say, we've removed this section because now in separate spec
RESOLUTION: resolved that, in preparing last call doc for RDFa, decouple RDFa syntax document from any separate CURIE document.
<Steven> +1
<benadida> +1
ralph: support this resolutionm, will save us time over next few months. can change our minds later, if XHTML WG puts out separate CURIE doc.
<edsu> ShaneM, I was confused by that too, although isn't that just a draft?
diego: I think, if we keep CURIEs inside RDFa syntax doc, then think carefully where to place it. it was some work to read the document, because use curies, then later read what curies are.
guus: but this is editorial comment. objections to resolution to decouple? [no] resolved by consensus.
ed: CURIE thing was my main comment. i had some trouble in steps of processing section.
guus: asked you as potential user of RDFa, whteher this is a description you could use?
<RalphS> [Ed, Shane; I believe the XHTML 2 WG's intent is to update the CURIE WD after experience with RDFa]
ed: yes, thought it was very
useful. diego's comments tightened up a few parts of it, but
thought it veruy useful.
... made me want to dig into implementation, see how things were working.
guus: any points in review you
consider critical, anything which needs to be answered, or only
editorial discretion.
... ?
ed: nothing critical.
<mhausenblas> Diego's review
diego: comments on titles,
request to move paragraphs to new section. Main comments are
related with processing rule...
... processing rules are clear, get the idea how to process, but some points e.g. we should make clear only elements are actually processed by the rules, not clear at the moment (text nodes, comments?). If you look at code of ivan's implementation, where it goes down in tree, has if element node, then go in [?]
mark: used to say meta - text - meta. in my implementation, bring text node up. but it's right [what diego said].
guus: going to decide now to publish new WD. doesn't need to be completely finished, just need considerable progress, and nothing there which will embarrass us. so focus on anything which could block publication as WD, and anything which can be left to editorial discretion.
diego: main point is processing rule 6, about how evaluation context is transmitted from parent to child. a mistake in rule, at least something which is not clear. have suggested some possible fixes, would be happy with any of them. would be happy to see doc go forward, if this comment is addressed, the rest are minor comments.
ivan: let's separate two things. there are mistakes, things to change in the doc. Decision to publish should not depend on that level of techincal detail.
guus: but that is your opinion. if diego thinks that is serious, as a reviewer, that is his opinion.
mark: both sets of comments were really useful, showed really good understanding. absolutely accept if there confusions, then genuine confusions. then both curies and stack issue need to be addressed.
guus: too much work to block quick publication?
mark: no, irony is implementations are better than processing description.
guus: summarise for this minutes as the "stack issue" ... so diego main thing you want fixed before publication?
diego: if fix comment about stack, then happy to publish as WD
<RalphS> [could the Chair or scribe clarify, please, how much fixing Diego is asking for]
guus: assume we have one more WD before last call. directly after this meeting publish new WD. give public change to comment. i.e. publish within 1-2 weeks. then in 1-2 months, go for last call.
ralph: which of diego's stack suggestions are critical? accept mark
<edsu> RalphS: diego's concerns were specifically about the 'stack'
ralph: long time since publish update to any RDFa spec. like to see us publish. hopefully can fix in next WD. looking for clarification from deigo on specific pieces of the stack section which he thinks are critical.
<Zakim> RalphS, you wanted to recommend proceeding
ivan: that was essence of my comment as well. try to be pragtmatic. hit publication moritorium in few weeks. if have to edit, hit moritoritum, then timing may go off. my preference is, even if there are mistakes, anything whiich can be fixed in 1-2 days should be fixed, otherwise publish, then try to get to last call in december. rather than get problems into doc now.
mark: split diego's comment into two parts: (1) idea of stack not good way to explain; (2) it's wrong. Suggest we follow your advice, still use idea of stack, but fix the error. before publication.
<RalphS> [good; if we can tweak the words in the editors' draft to fix a bug, then consider a bigger rewrite in a future draft, that would be nice]
diego: agree with ivan's point. ok to publish as it is, if we document that there open issues on the document.
PROPOSED: to publish new version of RDFa syntax document at the earliest possible convenience, no later than moritorium, taking into account comments of reviewers as far as possible.
<Steven> This will be the first PWD, so I will request a shortname
PROPOSED: to publish RDFa syntax
document as First Public Working Draft at the earliest possible
convenience, no later than moritorium, taking into account
... to publish RDFa syntax document as First Public Working Draft at the earliest possible convenience, no later than moritorium, taking into account comments of reviewers as far as possible, adding notes where there are open issues.
<mhausenblas> +1
<RalphS> October publication moratorium
RESOLVED
<edsu> benadida: coffee just arrived here funnily enough :)
<markbirbeck> +1 Ben :)
<markbirbeck> Just like to thanks the reviewers...very good work.
guus: move to next agenda item.
RESOLUTION: to publish RDFa syntax document as First Public Working Draft at the earliest possible convenience, no later than moritorium, taking into account comments of reviewers as far as possible, adding notes where there are open issues.
guus: next proposal, WG approves new version of primer for WD.
<mhausenblas> RDFa Primer
ben: the primer has been updated to match the syntax. It has has been updated to be less technical, more about events and contact information. now matches latest syntax. if don't have official reviews. do think pubolish new version soon is useful.
guus: first we need reviews, before publish again. postpone decision until we have two reviews from outside TF. is that a problem?
<RalphS> [oops, Guus is right -- we forgot to ask for SWD reviewers for Primer]
ben: we did get at least review from ? although don't know if that counts. urgent to get new version out, so need volunteers today.
<benadida> from Bob DuCharme
guus: volunteers? one review
would be ok. antoine, would you be willing to do again?
... telecon in two weeks time. ben, proposal would be to have reviews by telecon in two weeks time.
ralph: october 31 is last day we can ask for publication.
guus: two weeks, ok with you [antoine]?
antoine: yes
guus: syntax doc, all changes are
now at your discretion.
... back to the primer.
ben: ...
<RalphS> [[31 October, 12pm ET: Deadline for publication request before moratorium ]] -
guus: ben is fine with decision on 31st, and will have edits in time for moritorium
<RalphS> note, that's 9am Ben's time
ralph: that is 31 9am
ben: so 30th then
guus: we have a volunteer - antoine has volunteered.
<RalphS> Primer ready for review
<scribe> ACTION: antoine to review RDFa Primer before next telecon (within two weeks). [recorded in]
guus: next agenda item ... last
three proposals all to do with status of documents.
... understand TF is in favour of publishing syntax as rec, rest as note. Timing will be, publish others as note once rec is finished?
ivan: or goes to proposal
guus: note is end status. for the moment can stay as WD. notes only published once rec is final. e.g. if in rec process, need new test cases, then need to reopen note if published. note is end status in W3C.
ivan: GRDDL published like that
<benadida> Test Cases are not a note
<mhausenblas> +1
mark: how does that affect our agreement timing?
guus: see proposal to publish primer as note, seems unlikely. minimum 6 months for rec, so also minimum timing for note.
<benadida> I believe we meant to put on track to become a Note, not make it a note today
<mhausenblas> Maturity Levels
ralph: I think guus is right. note status is something like last call for rec doc. WG believes it's done, and doesn't expect to change. We can issue a new version of a note, but publishing as a note is really a statement to public that WG is done, doesn't expect any more work. I think guus is right, we should leave as WD, until confident unlikely to change any more. Once syntax doc is proposed rec, then freeze primer as a note. proposed rec stage time for note.
guus: did we publish RDFa use cases as WD?
ben: yes
guus: we can have updated versions if sufficient changes. las WD? [30 march]
<benadida> we have not updated the use cases doc
guus: link on latest version
doesn't go to previous WD
... document package: syntax doc, primer, use cases, test cases.
... has that been published?
ralph: TF has not proposed formal test cases doc.
<mhausenblas> Test Suite
ivan: test cases on wiki. don't know about plan to turn into TR doc.
guus: no plan to make test cases a WD?
ivan: don't think so.
<mhausenblas> TC approval
steven: test cases there to support going to CR. so not normal to take that to rec.
ivan: some groups have done that, choice of the group. RDF, OWL like that, other groups not. group decision, there is no rule.
guus: discussion on test cases as WD or not.
ralph: question of coverage and
editorial time. if had the time, and test cases cover good part
of spec, then should publish. TF didn't expect to do a test
suite that would have enough coverage to justify editorial
effort.
... we have added tests over time.
<Zakim> RalphS, you wanted to speak to 'Note' status
<Zakim> mhausenblas, you wanted to note on the RDFa TC
guus: for moment, package to publish is: syntax (rec); primer (note); use cases (note). test cases informal doc.
michael: acknowledge raolph. test cases at link above ... ???
<mhausenblas> Test Suite
guus: michael agreed, test cases on web site, not going to be a formal document
michael: doesn't need to be formal doc (W3C TR), no.
guus: consensus on this.
... proposal that RDFa primer be published as note, don't decide now.
ben: should agree that RDFa syntax will go rec.
guus: we have resolved that
syntax will go to rec, haven't resolved that primer will go to
note.
... up to TF ...
<Steven> Yes we did
ivan: guus wants to keep it open for TF to include other docs in rec
guus: ok to keep our resolution,
other docs to note.
... then we should record our intention to publish primer as note
ben: ok to leave open, but make sure it's ok for only syntax to be rec.
guus: yes, in earlier resolution.
<Steven>
PROPOSAL: that use cases and primer are published as WG notes around time that syntax reaches recommendation status
<mhausenblas> +1
<benadida> +1
guus: good to have syntax published without primer in final state.
<benadida> +1 to proposed rec
<mhausenblas> +1
ralph: change to "proposed rec"
rather than "rec"? do it when when WG asks for transistion to
proposed rec, then should freeze [other stuff]
... we should have everything done by proposed rec.
PROPOSAL: that RDFa use cases and primer are published as WG Notes not later that syntax reaches recommendation status
<benadida> +1
<benadida> "post-it notes?"
<mhausenblas> +1
steven: not yet asking for short names?
ralph: already have short names.
guus: published once already.
RESOLUTION: that RDFa use cases and primer are published as WG Notes not later that syntax reaches recommendation status
guus: proposal that test cases be used as supporting documentation...
michael: ???
guus: test suite comment in RDFa
syntax ...
... no "MUST" dependent on test cases I hope. If not the case, then i'm ok.
<Zakim> RalphS, you wanted to clarify shortname
<RalphS> Ralph: we already have approved shortnames the primer and use cases documents; our WG formal request to publish Syntax as First Public Working Draft will be when Syntax gets an approved shortname
ralph: wanted to clarify, we have three short names in our recent resolution. already have approved short names for firts two, when make request for syntax for third will get a short name.
<mhausenblas> what is about ->
steven: no objection to request transition?
guus: I'm ok.
<ShaneM> no it is not there....
guus: only item left on agenda, is thing we started with. any other issues?
<RalphS> is 404, so we can't say it's been approved. But I recommend that's the shortname we propose and I do not expect any disapproval
tom: two things. helful to set milestones, so we have targets to work towards. secondly, raise issue of wiki pages - there is comparison of charter milestones with progress in deliverables page, this should be kept up to date. [another thing?]
<benadida> see you in 9 minutes
<Steven> Request for publication sent
guus: (1) swd vs. xhtml WG; (2) planning; (3) admin, wiki pages etc.
<seanb> scribe: seanb
Guus: personal inclination to go as before. Task force has two hosts. Need to think who then takes decisions
Ivan: From activity POV, problem
is messaging side.
... RDFa document should bear explicit SW activity stamp
... important for community acceptance
... pragmatically don't know consequences if document published jointly.
... do both groups then have to issue the same resolutions?
... what if groups disagree??
Steven: If there's disagreement
it's problematic anyway.
... happy with joint work
... preference to do it in two.
Ralph: No problem. If there's
disagreement about spec, regardless
... then we have to react. Ivan's inventing a problem.
Mark: Task Force ok at collating
and representing both communities.
... worked well so far.
Guus: Group started widely spread. Social consensus has appeared.
<RalphS> [yes, the RDFa Task Force is the critical administrative thing that made this joint WG work practical]
Mark: Twin approach is good for a
marketing POV.
... good to be seen as not coming just from SW community
<RalphS> Ralph: the only real novel question I see in this joint REC-track work is in the Director's Decision on the relevant transition requests. Let's let W3C staff deal with that technicality and not worry about it as a WG.
Guus: See consensus here. Only
need to see operational issues
... should have discussion with chairs and resolve among ourselves how to
... proceed. Critical points/formal steps should be decisions from
... both groups, but not for everything.
Ralph: WG chairs sync via email.
Rely on the task force to ensure groups are
... coordinated. TF in place to do the sync.
... Rely on Mark, Steven and Shane to flag things that the XHTML 2 WG might disagree with.
<RalphS> Ralph: I suggest that the only formal points where we explicitly look for dual resolutions is on transition requests, and otherwise rely on the Task Force to coordinate the two WGs
Mark: How do arrive at
resolutions from two groups?
... TF co-ordinates receiving two requests
Ralph: don't get overly concerned about procedural matters.
<RalphS> Ralph: just a matter of how the SWD WG participants in the Task Force are coordinating with the SWD WG
<scribe> ACTION: Guus/Tom to propose joint decisions for reviews for major steps/transition requests. Informal agreement about working drafts. [recorded in]
Guus: Planning
<RalphS> (the task force coordination may be handled by XHTML 2 WG representatives in whatever way the XHTML 2 WG chooses)
Ivan: Ideal Rec by AC meeting in
Beijing
... would be good to publish while WG is still inexistence
... Big surge in interest in RDFa. Good to ride on this wave.
... PR beginning of March. CR phase will bbe short. CR early feb, late jan
Steven: If we have the implementations, zero lenght CR
Ivan: Would prefer short (from
messaging POV).
... ideal last call end of december
Guus: concerned that's not engough. Beginning december better
Steven: One more WD, then take that to Last Call.
Ivan: not many issues, and none are major.
Guus: Needs full review process from two groups
Ivan: Work has to be done mid-November
Guus: Need to have reviewers
lined up and agreements with XHTML WG.
... documents need to be ready for review 16/17 November
Mark: This should be ok.
Ivan: But not to raise new issues!
Guus: Four weeks absolute minimum
for LC
... if there is attention for RDFa, then may need to plan for lots of comments
... need to convince ourselves that this is then just editorial.
... editing of last call comes to mid feb.
... then two weeks contingency for CR
Ivan: Meantime, need implementation report. Regardless of CR period.
Guus: Imp report mid feb.
<ShaneM> Note that we can prepare an implementation report now - Ben, can you take an action item to do that?
<benadida> yes, I can take an action to do that
Ivan: May get LC comments like "I want to do reification". Would cause problems
Mark: Should we try and anticipate these.
Ivan: Perhaps. Include comments
e.g., "we have decided not to include feature X".
... need to be prepared for this as LC comments come in.
Guus: TF need to plan time for editing. Don't expect that it won't be much work.
Ralph: Use UC documents as a guide.
Guus: TF has to have the frame of
mind to not add new features or open issues.
... feature freeze
<RalphS> Ralph: we should be in feature freeze in the next few weeks
Guus: Would like to record a
draft schedule.
...
... Mid november documents for review
... Early december both WGs vote on pub of LC
... LC period ends second half of Jan
... Request for CR mid Feb
<benadida> can we give someone (me?) an action to record this schedule?
Guus: both WGs need to decide on
this
... Two weeks CR
... Implementation report to be written
<Steven> you can do it yourself Ben
Guus: First week March, both WGs
decide on request for PR
... Beijing (end April) RDFa REC
<mhausenblas> Will be reflected in -> RDFa schedule
<ShaneM> ACTION: Ben to prepare draft implementation report for RDFa (with assistance from Michael) [recorded in]
<benadida> ACTION: Ben to update RDFa schedule in wiki [recorded in]
Ivan: AC Meeting 21/22 April. Publishing moratorium before that.
Tom: Adminstrative points
... Are all TF members considered to be in both XHTML and WG?
Ralph: one or other but not necessarily both
Tom: Deliverables page for SWD.
Milestones from charter.
... Request that we update that page with current intentions/schedule
<mhausenblas> points to
Tom: Request RDFa page be brought
up to date in light of these decisions.
... Danger that things could get out of sync. Explicitly flag as something to discuss
... with XHTML. Would be good to have a central up to date page.
... don't want to maintain different pages in different WGs.
<mhausenblas> IMHO is the main page
Tom: wants someone from TF to have responsibility for this, so we know who to ping.
Guus: Other technologies (e.g. OWL) had pages outside of WG
<ShaneM> FWIW I do not believe the XHTML 2 Working Group has any RDFa pages we are maintaining (other than the draft documents of course).
<mhausenblas> Note that there is for good reasons an RDFa page at -> ESW
<Antoine>
Ivan: Is this right?
<mhausenblas> so eg. ?
Tom: Right now two pages. Ok for
internal use, but doesn't look as polished
... to outside world.
Ed: RDfa.info domain should be updated
<benadida> rdfa.info is kept relatively up to date, with some holes of course.
<edsu>
Ivan: not maintained anymore. Neither is 2004/OWL
Guus: Point from Tom is clear. leave it up to the TF to tackle this.
<Steven> We should put a Specifications link on rdfa.info too
Guus: Main point is up to date schedule. One point where main information is.
Ralph: As a WG can't decide on
long term issues. Decisions about top level technology
pages
... on w3c site is out of ourhands.
<scribe> ACTION: Ben and Michael to address comments by Tom [recorded in]
<benadida> updating it now
Guus: Done with formal part
<Steven> Thanks Shane
<edsu> ShaneM++
<mhausenblas> f] will be back for 'Review of Cool URIs' some time before 15:00UTC
<RalphS> [I don't expect scribing during Mark's informal presentation, but would appreciate URIs when feasible]
<edsu> looking at;
<RalphS> ""If the slightest probability for an unpleasant event to happen exists, the event will take place, preferably during a demonstration." --
<RalphS> [I wonder why Ben's RDFa Highlight reports apparently two identical triples for the audio samples]
<RalphS> [perhaps the apparently "identical" triples is really a rendering bug with two properties in the same @property attribute]
<RalphS> [or, in the case of bitmunk.com, in the same @rel attribute]
<edsu> now looking at:
<benadida> still there, but sounds great
<RalphS> [I'd appreciate it if someone in the room -- Ivan perhaps -- would fill in the names of the others in the room]
<Steven> +2 others
<Steven>
<Steven>
<RalphS> Ed, are Justin and Jon also present?
<edsu> Jon is here, Justin is not
<RalphS> thanks, Ed
<RalphS> maybe Vit was the other in the room, then?
<RalphS> [I'll ask again when folks return from lunch]
<edsu> Vit just got here about 1/2 an hour ago yeah
<RalphS> ok. And you're aware in the room that you're no longer on the phone?
<edsu> yes, i am at least ... i'll make sure it'a back online at least by when we resume
<RalphS> :)
<edsu> unless you want to hear the clinking of plates and random chatter
<inserted> scribenick: edsu
Tom: goals are to agree on the
semantics for the 3 labelling properties, and then agree on how
to specify those semantics
... alistair can we jump into subtopic A?
aliman: if anyone wants any
background, let me know
... discussion is just about the three uris: prefLabel, altLabel, hiddenLabel
can you hear us ok?
aliman: sub-topic A is about the
ranges
... the options are 1) rdf plain literal 2) allow the range to be open ended and say that it includes plain literals and perhaps other things
... i prefer the 1st option because i think there are valuable semantics like disjointness and cardinality that become difficult to state with option 2
Antoine: could we postpone given the relationship between labels topic?
aliman: i'd like us to consider this in isolation
Jon: can we back this decision out if we need to reconsider during labelling relations discussion?
aliman: I don't see why not
Tom: I agree this is a very
dependent decision
... if the consequences are too painful we can revisit
... i'd like to get a sense of where we stand with these 2 options
ivan: in practice you could also
use strings for the same purpose
... pretty hair to express the union of strings and literals too
Antoine: how about someone could
creat their own type that includes strings and literals
... I don't see the point in restricting to plain literals
aliman: i know how to express the disjointness and cardinality using plain literals ...
Antoine: are you sure we can't do this with typed literals?
aliman: can we move on to the next two?
ivan: this reminds me of the discussion at DCMI
aliman: in dcmi there was discussion of more general consequences of using literals, and here the issues are specific to expressing cardinality and disjointness
aliman just brought up
on the projector
seanb: what are you trying to express in option 2?
moving on to Sub-Topic B: Disjoint Properties
aliman: put examples in the
document of things that we shouldn't be able to say
... we need to be able to say these are pair-wise disjoint
... do we need to consider any other options
... ?
ivan: was the disjointness from english prose in the text?
guus: you mean "must" be pairwise
disjoint, instead of "are"
... i can't think of any use case that would object to this
Antoine: I agree
tom: do we have consensus?
RESOLVED (for subtopic B) The property extensions of skos:prefLabel, skos:altLabel and skos:hiddenLabel must be pairwise disjoint
Antoine: the 3rd point is the
cardinality of skos:prefLabel
... implicit in the decision to have a prefLabel is that there is only one prefLabel
... the first example is where the same resource has two prefLabels in the same language -- do we agree that there is something wrong with that?
... there is a complication where a language is written in different regions, or with different scripts
guus: once the language code changes you're allowed a new prefLabel
aliman: to be pragmatic we only have one choice
<RalphS> [apologies; I was 2 rooms over and didn't hear the meeting resume]
aliman: i used rfc 4646 for the definition of language tag
ivan: i am not sure i understand, what's the problem?
guus: so this decision was dependent on subtopic a
aliman: i tried to think of this
independent of the design patterns
... a resource can have a preferred literal and only one per language
... our idea of a language comes from RFC 4646
tom: whether a rdf plain literal
refers to rfc 4646
... in answer to ivan's question about the issue w/ rfc 4646
<RalphS> [I'm more in favor of SHOULD NOT rather than MUST NOT ]
guus: we might not be able to
express it
... not sure we have the machinery, but happy to go with this, if natural language is sufficiently precise this will be clear for implementors
RalphS: how strongly do we feel
that constraints need to be in OWL? if i understood guus
correctly leaving a little flexibility here is good since we're
dealing with natural languages
... constraints like MUST NOT are much stronger than what we need for applications like SKOS
tom: we are trying to get consensus on what we intend, and later talk about the best way to do it formally
guus: the statement is intentionally vague
<RalphS> [I just heard Guus say "... can not ..."; is that SHOULD NOT or MUST NOT?]
aliman: at this stage i was hoping we could agree on the sentences
<RalphS> [I don't mind vagueness but the SHOULD [NOT] language seems to me to accommodate the necessary vagueness here]
[they are proposing to resolve with the text as is]
RESOLVED (for subtopic C) A resource cannot have more than one preferred lexical label per language (where it is assumed that each distinct tag allowed by RFC 4646 denotes a distinct "language").
aliman: here we are formally stating a semantic condition
seanb: i think the issue here is that this statement may not get expressed anywhere else
guus: skos is not the same thing
as owl, we need to show developers what they should do
... they look for situations where they might find more than one prefLabel, and what should they do?
<RalphS> [I'm not particularly in favor of telling apps what to do if they find a violation of a constraint]
sub-topic d: super property
aliman: at the moment they are all subclasses of rdfs:label
<RalphS> [I'm confused -- did we change from "cannot" ? ]
aliman: I can't see any reason to drop it
[RalphS we haven't ... maybe pipe up on phone to get them to go back]
aliman: we have resolved to build semantics on owl full, so i can't think of any reason to drop this
<RalphS> [I'm not worried about OWL DL and think that more apps will usefully take advantage of rdfs:label
guus: it's a feature we often use, from the DL spec
seanb: i think that's fair enough
guus: won't hurt many people in the DL world
<RalphS> [thanks, Ed; I'll let it pass for now. I would only object to a MUST NOT decision w.r.t. label disjointness constraints]
diego: i have concern about hiddenLabel because it might be get taken as a prefLabel
aliman: that's a good reason why you might drop it from being a subclass
guus: the problem with that distinction is the notion of authority
seanb: it seems strange to break the spec to cater to those who are not respecting the spec
guus: if a vocab owner wants to
enforce it, they need some sort of authority set up, and that's
outside the scope
... recurring theme, and we should deal w/ the issue as it is outside of scope
Antoine: is it worth noting that this is a problematic axiom?
guus: there are a few of these situations, would be useful to list carefully details about OWL DL
<scribe> ACTION: alistair to update semantics document to listing ways in which ways SKOS diverges from OWL DL [recorded in]
RESOLVED skos:prefLabel, skos:altLabel and skos:hiddenLabel are all sub-properties of rdfs:label
ivan: would the list be kept with respect to owl 1.1?
guus: not going to make skos work dependent on newly formed working group
sub topic e: Formally Stating the Range Semantics
aliman: if we choose the range to
be plain literals then how do we state that?
... we could use rdf triples to state the range, but there's no URI for rdf plain literals
... or we could use normative prose
guus: is this a problem?
aliman: the question is how are we going to express our intentions, a valid question is whether it is worthwhile stating it formally
RalphS: why would minting the uri not haven any value?
<Zakim> RalphS, you wanted to ask Alistair why he doesn't believe there's value in minting a URI for the subClass of rdfs:Literal wanted by SKOS
aliman: i didn't know any applications that would need that expressed in triples
RalphS: how is that different from the disjointness inferencing
aliman: if there's a clash
between a prefLabel and an altLabel then applications would
break
... but i'm not sure they need to do the same with it being a plain literal
RalphS: i agree about the range semantics, but you do seem to want to put the constraints into other places, there seems to be a mental model that you have that i'm trying to understand better
aliman: we should probably state things formally: either as rdf triples, or as some sort of prose
guus: are you trying to solve something that even the owl community hasn't tried to solve?
aliman: lets move on to the next subtopic then
TomB: aren't we saying that we want to move normative prose and agree on option 2?
<RalphS> [if we're trying to drive a generic editor from these constraints then I can understand wanting to formally specify an rdfs:range -- however, I doubt that will be as useful for SKOS. The benefit of the rdfs:range on inferring the type of an Object is pretty small for SKOS IMHO]
RalphS: we can make some auxiliarly triples available
<Zakim> RalphS, you wanted to propose an auxiliary triple set whose purpose is to suggest more thorough validation of a [merged] graph
guus: it means (w/r/t issue 26)
if you would need separate property for labels that represent
literals and labels that represent resources
... i'm tempted to go in the direction of explicit labels
... the semantic conditions for one language get more difficult to express
aliman: i think i can state the language constraint :)
guus: at some point we have to swallow this potato
aliman: why don't we swallow the potato with option 1, and see what we can do, and what we can't do
RESOLUTION: The range of skos:prefLabel, skos:altLabel and skos:hiddenLabel is the class of RDF plain literals.
scribe: (subtopic A)
antoine abstains
<RalphS> (and that class needs a URI, which SWD might coin for this purpose?)
<seanb> Depends on how this is stated though...
<RalphS> (we can come back to the URI question when we decide how much to state formally in RDF)
guus: all semantic conditions for a prefLabel and a prefLabelResource would have to depend on a super-property
[guus is drawing on white board]
aliman: it's easier if you do two separate properties
guuss: prefLabel, altLabel and
hiddenLabel also are dependent
... it's a potential issue
aliman: i don't see how it gets any easier if you have them all inherit from one property
Antoine: might make axioms easier to construct (sorry i missed details of that)
[short break]
<RalphS> [is it the same people in the meeting room this afternoon as in the morning, with Vit's arrival? Perhaps Mark and Steven have departed?]
yes, both mark and stevan left
<RalphS> thanks, Ed. And no one else has arrived, I gather
correct
[do square brackets mean it's invisible to the minutes?]
<RalphS> [no, it's just my notion for an administrative sort-of message]
[ok :)]
<seanb> scribe: seanb
Antoine: Problem with plain
literal as range.
... Two issues.
... 1) Concepts linked to literals
... 2) Concepts linked to resources
... If we have
... c skos:prefLabel R
... R label "shrub"
... then we create a new triple
... c skos:prefLabel "shrub"
... so any triple invovling the resource, would entail a triple invovling the literal.
... might actually be:
... c skos:prefLabelR R
... then can state conditions as "a concept can only have one prefLabel which is a literal".
<TomB> scribe: edsu.
moving on to subtopic f
aliman: looking at ex:foo
skos:prefLabel ex:bar
... all we get is ex:bar is a plain literal
... we could state a syntax constraint
... Firstly, do we want to state a syntax constraint? (yes/no)
... and if we do, how do we do it?
... we could use normative prose or sparql -- not much precedent for this
... and thirdly what do applications do with that constraint?
... does the application generate an error or quitely handle it?
TomB: i think you're making an assumption that if we do want to express contraints that we need to define application behavior
guuss: we can make a spec and say
tools SHOULD ...
... my proposal is that we have a general rule MUST, SHOULD or MAY and you might have some exceptions
aliman: what are the options for an application?
RalphS: i strongly think in this
particular case we shouldn't advocate particular application
behaviors
... don't want to madate the behavior of user interface
... do you want your cellphone to flag a warning when it encounters a skos error?
seanb: what's a skos
application?
... we need to narrow down the applications that are consuming these things: vocabulary checker for example
<Zakim> RalphS, you wanted to suggest that for purposes of SKOS we should not tell applications how to handle errors
aliman: what do we call this class of application?
seanb: it's a vocabulary checker
aliman: i'm happy to define a class of application and go from there
guus: i had vocabulary checker in my mind when we were talking about this
aliman: can we resolve that yes, we want to include contraints and a skos vocab checker must raise a warning
<RalphS> if Guus:SKOSapplication is the subclass that is doing formal SKOS vocabulary checking, I'm more comfortable :)
RESOLVED that the validating application under discussion is a vocabulary checker, and what we're trying to decide is how a vocabulary checker should handle violations of constraints
RESOLVED where label properties are used as predicates the object must be a rdf plain literal
<RalphS> as an editorial convention, then, for the benefit of our future readers I suggest we use a modifier term such as "validating application"
<RalphS> :)
moving on to sub topic G
<RalphS> (I'm suggesting "validating application" in the REC spec too :)
aliman: here we come back to
disjointness, and how we formally state it
... one option is to use some prose
... we could use the conventions set out in rdf-semantics
guuss: if we follow the first approach there will be someone who writes a document for these formal semantics
<RalphS> will any of our expected readers want to see the degree of formal semantic language used in [RDF-SEMANTICS] ?
guuss: i would be very happy w/ the first option
seanb: how do you expect it to be used? if you are doing vocab checking you will be ok w/ option 1
<TomB> Elisa, hi! Are you ready to start VM topic at the hour?
RalphS: it seems to me the community of practice might be more comfortable with option 1
aliman: the idea would be the skos semantics would be rigorous, and the skos primer would have the less technical description
<Zakim> Ralph, you wanted to suggest there's grave risk in making SKOS look complicated
<RalphS> (actually, to clarify, I believe there's grave risk in making the principal SKOS Recommendation document look complicated]
guuss: there are advantages to unamgibuously stating things
seanb: it's a trade off
TomB: we need to wrap up this subtopic and move on to vocab management
RESOLVED (subtopic G) use normative prose to state a semantic condition on the interpretation of the three properties: prefLabel, altLabel and hiddenLabel
<Antoine> scribe:Antoine
<RalphS> Vocabulary Management [Wiki] Draft
Elisa: collect has been collected
from different people...
... overview of several topic area that we think are important
... to give people pointers to work out there, best practices
... not list of exact receipes
... for a number of problems there is not necessarily one good way
... this document tells what you should think about when creating your RDF voc
... [listing of the different parts of the document]
... the issue is very important for metadata mngt in general
... linked to some documents released by OMG?
... which has been using the term "ontology" for a while
... OMG has issued a "document management scheme"
... with issues that are of interest
... the first thing I'm looking for from the group is to step back
... considering briefly what exists eg with XML schema
... and makes people comfortable
... also commercial perspective, w/ vocabularies living a lot longer than imagined
... also a standardisation aspect (government concerns, LoC)
Guus: observation: given our resources, it would be wiser to focus on RDF vocs
Tom: I'd be relunctant to extend
the scope outside of RDF
... but if we did have a well-formulated set of principles for RDF
... it could be useful for other kinds of vocs
Elisa: I agree
Guus: question: current doc has 5 sections: are these the 5 that are adequate?
Elisa: yes, but one more topic
(perhaps under documentation): provenance
... when developing your ontologies, pointing at sources
... we should inclue that
Guus: question about authority:
which part of the vocabulary published on the web is
yours
... is it included?
Elisa: not. It could be related to provenance, but is separate
Guus: if you use broader link between 2 vocs: which triples do you sanction then?
<edsu> Elisa: it seems somewhat related to "An RDF description of an RDF vocabulary should be published. Potential users should be clearly informed as to which is the 'authoritative' RDF description of an RDF vocabulary." in there
Ralph: we just have the policy to put it in your namespace
Guus: you can have a guideline on using ontologies and owl:import
<RalphS> we'll want to do more trust statements eventually, but I don't think we want to try to tackle that in the current lifetime of this WG
Elisa: first section on URI for
naming with discussion on Cool URIs is in shape
... needs perhaps a few URIs
... and examples (bioportal?)
... the second section could be added with information from the work of OMG
<danbri> (to comment from sidelines ... I'd suggest "an" authoritative, rather than "the" authority. The word "the" is appropriate to indicate there is but one authority, ... but that authority might write various descriptions)
Elisa: including DC and SKOS as considerations
<danbri> (esp with xml-sig or pgp-signed statements, descriptions can be scattered)
<RalphS> (there's clear overlap between the
Elisa: the third section is an area that needs help
<RalphS> "readable documentation" section and the SWEO URI note on content negotiation)
Elisa: we should come with a
short list
... on what people have done
... the fourth section could be added with pointers
... finally publishing a formal schema section could be added with examples
... and point back to the receipes doc
... this section should not be very big
<TomB> RalphS you have a strong echo
Elisa: Ralph: if we can point to examples of policies
<TomB> ...hard to understand...
Ralph: useful contribution could be to suggest which parts of a voc are stable, which parts need development
Elisa: agree with Ralph
proposal
... OMG stuff should bring useful info
Ralph: in SKOS draft we have some notion of stable/unstable
<TomB>
<Zakim> Ralph, you wanted to comment on maintenance policies -- make or buy?
Vit: talk + input for
discussion
... 3 contributions from Knowledge Web
... ontology version survey
... ontology versioning impl
... setting for inference in dynamics
... Vocabulary mngt has a lot of synergies with ontology dynamics
... 1: results of survey of key industry and academia players
... intended as a requirement analysis for SemVersion
... 3 main sections: background, approaches to versioning, required features fro versioning
... observations: tools are needed
<RalphS> [Vit is presenting from slides? Are those in the Web?]
Vit: dichotomic understanding of
VM topic (repeated editing of one version vs. multiple
releases)
... agreement on basic metadata, importance of discussion
... multi-version reasoning is welcome
... (really academic, C-OWL)
... [Presentation of SemVersion]
scribe: not dependant on a
store
... there is a MD model for versioning
... SemVersion can be called via API, for Java
... Prot�g� plug-in
... [inference in dynamic settings]
... all this inference stuff is work in progress, mainly academic
... bridging concepts accross different versions
... [Suggested progress]
... results of the survey could be reflected in the VM doc
... introduction could reflect the multiple ways of voc maintenance
... sec2 on doc can be extended by rec on change documentation and discussion process MarcOnt Portal, Prot�g� CHAO ontology)
... sec3 on maintenance policies can benefit from change documentation
... sec 4 with reference to versioning metadata
... [SemVersion implementation can also be reflected in several parts]
... [Inference: less sure what should be put in the document]
... logical consequences of changes
... for section 2
Guus: How far are you from
bridging this to the VM doc?
... especially to the use cases
Vit: it's tricky. Even SemVersion is a research prototype
Guus: what are the elements that you have that would fit the draft. Examples of what people do?
Vit: people use subversion, CVS, detecting the syntactic changes
Guus: many vocabularies are reinventing the wheel
Vit: the survey was meant as
requirement analysis
... not exactly in details e.g. on how people use CVS
Guus: if people are real people with the same needs
Vit: they had almost the same requirements
Ed: is this document on how people should do subversion?
Jon: raw results survey?
Vit: this was sent to the
list
... not the raw results. I can check if it is doable
<TomB> mhausenblas, you are ready to discuss Cool URIs?
Guus: about maintenance policies?
<TomB> ...or do you have a phone problem?
Vit: some experience with Digital
Library project
... they are re-building their platform
... it has been used for mediation between different library-related models
... there was something done, by one group
Guus: more on MD format than on vocabulary side
Vit: example on how people interact when developing
Guus: they're not vocabulary owners
Vit: they cooperate with library
people
... we are discussing with them
Tom: step back, look at the
charter
... if we agree that the 5 heading are reasonible
... I see a danger in going into too much detail
<RalphS> ?? oops
Tom: it might be practical to
keep to current length, even shorten it
... if we go into more details, we'll run into problems
... first would be editorial, with parts having more details
... also we're at the border between what is good practice and what is experimental
... the draft has not moved significantly in the past
... we need to know what the final product should be
... I hesitate to suggest we can much beyond than identify versions
Vit: maybe we don't have to go into detail and point references
Guus: if we keep very short I'd
like examples
... based on Vit's survey which can provide good practices for version mngmt
Tom: for sbdy who is approaching
RDF vocabulary from outside, what do you need to think?
... we have not questioned the headings of the text
... we should keep it and provide footnotes in different directions
... e.g. versioning policy for Dublin Core
... but not to try to build up a substantial set of guidelines
... would it be valueable to have such a document?
Elisa: I agree with Tom
... we could point to the result of the survey in a paragraph
Guus: KW could contribute two
sections for the documents, 1-2 pages
... on version management, maintenance
... define 5 or 7 sections, allocate person for sections
... compiling and gettting it out
Ralph: suggestion for Vit: survey was anonymous, but identification of examples is possible
Guus: we all agree on this. Vit
and Elisa can come with annotated version of the document
... with actions to be taken by persons
<scribe> ACTION: on Vit and Elisa to include in the document all the target sections plus an allocation of sections to people and potentially a standard structure for sections [recorded in]
Tom: there is an issue about the document giving two definitions for a RDF vocabulary
Alistair: I wrote the two ones!
<mhausenblas> Summary of Cool URI review
<mhausenblas> Goal for SWD feedback
Michael: Leo asked for feedback from SWD
<mhausenblas> Possible solution to Vit's concern
Michael: Vit: indeed it is a kind
of solution
... I would like it to be mentioned more explicitly
... about readable content of triple
<RalphS> Michael: ask SWEO to consider whether all the design recommendations still apply to GRDDL-able documents
<RalphS> ... or are they primarily for cases in which the HTML and RDF are in separate documents
Michael: the minimal solution
should be to put it in the scope
... it needs to be mentioned
<RalphS> "I say 'RDFa' because it's a lot easier to say than 'GRDDLable'"
Michael: I have volunteered for reformulating the Wiki page
Ivan: I think Leo and Richard would not be happy to go into the complete RDFa/GRDDL
Ralph: some of the rec they're making not apply in the case of RDFa/GRIDDL document
<mhausenblas> +1 to Ralph
Ralph: we can point to specific
parts
... they need quick feedback
Tom: Michael, you suggested
putting the editorial issues back, focusing on one/two
issues
... first: what we say about RDFa/GRIDDL docs
... minimal solution is to acknowledge that they read the doc to see which design recs would not apply
... and acknowledge in the scope these issues
Michael: e.g. the redirect solution: we cannot do that with RDFa
Tom: you're willing to take an action on making a specific recommendation?
Ed: maybe we could provide an examples of how we see a RDFa doc fitting in the Cool URI doc
<mhausenblas> +1
Ed: the core of the doc in on
non-information resources
... while RDFa is about information resources
Tom: we need a well-formulated text
Ivan: what is intended?
... anything more than a mention is a scope is a grey area
... they did document the current status, as provided by TAG and others
... I would not like any additional technical work in the doc
Tom: Michael can only recommend the mention in the scope
Ivan: OK
<scribe> ACTION: Michael to summarize the discussion and the wiki page and formulate a scoping remark as a draft suggestion from SWD to the authors of Cool URIs [recorded in]
Ivan: from the SWEO side we need to know where the document stops from your point of view
Tom: if we can get back to Leo within two weeks we're in his target
<RalphS> [I hope Michael will still post his editorial comments to Leo, if only as an individual contribution]
Michael: we already discussed the issue raised by Vit
Ivan: I have put a copy of the doc on the W3C site
Guus: topic is closed
<ivan> W3C URI for the Cool URI document
<RalphS> [adjourned for day 1]
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/I'm no/I'm now/ Succeeded: s/. pref/. My pref/ Succeeded: s/as public/as First Public/ Succeeded: s/ph/v/ Succeeded: s/ShaneM:/ShaneM,/ Succeeded: s/Diego'S/Diego's/ Succeeded: s/, ???/. It has/ Succeeded: i/follow agenda, put/Topic: RDFa Succeeded: s/fix /freeze / Succeeded: s/notes /Notes / Succeeded: s/from/just from/ Succeeded: s/Raph/Ralph/ Succeeded: s/run things/flag things that the XHTML 2 WG might disagree with/ Succeeded: s/ wo/ two/ Succeeded: s/technology/technology pages/ Succeeded: s/TF/Ben and Michael/ Succeeded: s/ --/,/ Succeeded: s/there were/there was discussion of/ Succeeded: i/TOPIC: Labelling/scribenick: edsu Succeeded: s/RalphS: can you/can you/ Succeeded: s/RalphS: thanks// Succeeded: s/vaugue/vague/ Succeeded: s/#// Succeeded: s/the application under/the validating application under/ Succeeded: s/GRIDDL/GRDDL/ Succeeded: s/feeting/fitting/ Found ScribeNick: aliman Found Scribe: seanb Inferring ScribeNick: seanb Found ScribeNick: edsu Found Scribe: seanb Inferring ScribeNick: seanb Found Scribe: edsu Inferring ScribeNick: edsu Found Scribe: Antoine Inferring ScribeNick: Antoine Scribes: seanb, edsu, Antoine ScribeNicks: aliman, seanb, edsu, Antoine Default Present: Ralph, Ben, +043316aaaa, mhausenblas, Guus, Steven, ShaneM, Tom, Ivan, Sean, Alistair, Simone, Mark_Birbeck, Ed, Diego Present: Ralph Ben +043316aaaa mhausenblas Guus Steven ShaneM Tom Ivan Sean Alistair Simone Mark_Birbeck Ed Diego Agenda: Got date from IRC log name: 8 Oct 2007 Guessing minutes URL: WARNING: No person found for ACTION item: on vit and elisa to include in the document all the target sections plus an allocation of sections to people and potentially a standard structure for sections [recorded in] People with action items: alistair antoine ben guus michael tom[End of scribe.perl diagnostic output]