SWD WG Amsterdam F2F -- 8 Oct 2007

<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

RDFa

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.

<mhausenblas> Ed

<mhausenblas> Diego

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: http://www.w3.org/MarkUp/2007/ED-rdfa-syntax-20070927/#s_curies

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 comments of reviewers as far as possible.
... 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 ]] - http://lists.w3.org/Archives/Member/chairs/2007AprJun/0104.html

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 http://www.w3.org/2007/10/08-swd-minutes.html#action01]

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> http://www.w3.org/2007/10/08-swd-irc#T07-43-19

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 -> http://www.w3.org/TR/rdfa-syntax

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> http://www.w3.org/TR/rdfa-syntax 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 http://www.w3.org/2007/10/08-swd-minutes.html#action02]

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 -> http://www.w3.org/2006/07/SWD/wiki/RDFa#RDFa_schedule RDFa schedule

<ShaneM> ACTION: Ben to prepare draft implementation report for RDFa (with assistance from Michael) [recorded in http://www.w3.org/2007/10/08-swd-minutes.html#action03]

<benadida> ACTION: Ben to update RDFa schedule in wiki [recorded in http://www.w3.org/2007/10/08-swd-minutes.html#action04]

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> http://www.w3.org/2006/07/SWD/wiki/Deliverables#RDFa points to http://www.w3.org/2006/07/SWD/wiki/RDFa

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 http://www.w3.org/2006/07/SWD/wiki/RDFa 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 -> http://esw.w3.org/topic/RDFa ESW

<Antoine> http://www.w3.org/2004/OWL

Ivan: Is this right?

<mhausenblas> so eg. http://www.w3.org/2007/RDFa ?

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> http://rdfa.info

Ivan: http://www.w3.org/RDF/ 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 http://www.w3.org/2007/10/08-swd-minutes.html#action05]

<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; http://bitmunk.com/view/media/6068744

<RalphS> ""If the slightest probability for an unpleasant event to happen exists, the event will take place, preferably during a demonstration." -- http://www.joke-archives.com/oneliners/if.html

<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: http://magnatune.com/artists/albums/burhoe-invocation/

<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> http://rbenjamins.blogspot.com/2007/05/new-gartner-report-on-semantic.html

<Steven> http://yahooresearchberkeley.com/blog/2007/05/16/the-emerging-semantics-web-the-semantic-web-is-dead/

<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

Labelling properties

http://isegserv.itd.rl.ac.uk/public/skos/2007/10/f2f/labelling-properties.html

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 http://www.w3.org/2006/07/SWD/wiki/AmsterdamAgenda?highlight=%28amsterdam/SKOSLabellingProperties

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 http://www.w3.org/2007/10/08-swd-minutes.html#action06]

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

RESOLVED (for subtopic e) State in normative prose that the range of the SKOS lexical labelling properties is actually the class of RDF plain literals; retain the current declaration in RDF triples that the range of these properties is rdfs:Literal.

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

Vocabulary Management

<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> http://www.w3.org/2003/06/sw-vocab-status/ns#

<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]

http://smile.deri.ie/resources/2007/10/w3cf2f-vm.pdf

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 http://www.w3.org/2007/10/08-swd-minutes.html#action07]

Tom: there is an issue about the document giving two definitions for a RDF vocabulary

Alistair: I wrote the two ones!

Cool URIs

<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 http://www.w3.org/2007/10/08-swd-minutes.html#action08]

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]

- DRAFT -

SWD WG Amsterdam F2F

8 Oct 2007

Attendees

Contents

RDFa

Labelling properties

Vocabulary Management

Cool URIs

Summary of Action Items

Scribe.perl diagnostic output