W3C

TAG F2F 14 June 2006

14 Jun 2006

See also: IRC log

Attendees

Present
Tim_Berners-Lee, Dan_Conolly, Norm_Walsh_(part_of_day), Noah_Mendelsohn, David_Orchard(part_of_Day), Vincent_Quint, T.V._Raman, Ed_Rice, Henry_Thompson
Regrets
None.
Chair
Vincent Quint
Scribe
Tim Berners-Lee, Noah Mendelsohn

Contents


[Scribe for morning is Tim]

Metadata in URI

We are discussing: http://www.w3.org/2001/tag/doc/metaDataInURI-31-20060609.html

NM: I collected feedback on the metadataInURI draft, and made a list of what I thought responders wanted me to do.

NM: I don't expect this a last draft for a finding, but it should have several issues addressed.
... The issue I heard most loudly was that there wasn't distinction between people's and software's responsibilities.

NM: ... Section 2.1: The constraint something like "people and software should not depend on" it now says "software".

<noah> (quoting from the draft) "Note that the constraint refers to conclusions drawn by software, which must be trustworthy, as opposed to guesses made by people. As discussed in 2.3 Guessing information from a URI, guessing is something that people using the Web do quite often and for good reason. Software tends to be long lived and widely distributed.

<noah> "Thus unlicensed metadata dependencies in software result not only in buggy systems, but in inappropriate expectations that authorities will constrain their URI assignment policies and representation types to match the dependencies in the clients. For both of these reaons, the constraint above requires that software must not have such unlicensed dependencies."

NM: That last para was added.

<noah> Constraint: Web software MUST NOT depend on the correctness of metadata inferred from a URI, except as licensed by applicable standards and specifications.

TVR: By 'unlicensed" we shouldn't give the impression of real licensing in the legal sense. Maybe "documented"?

[Consensus on the change.]

<noah> The note I sent announcing the new draft is here: http://lists.w3.org/Archives/Public/www-tag/2006Jun/0037.html

<noah> The note explains the changes I tried to make in this round.

<ht> http://www.w3.org/2001/tag/2006/06/13-afternoon-minutes.html

NM: There was a section 2.8 which concluded that in the end, this is a bad thing to do.

TBL: Overlap between the constraint and the good practice?

<DanC_lap> hmm... re redundant boxes... suboptimal... not sure how to fix.

<noah> From the conclusions: People and software using URIs assigned outside of their own authority should make as few inferences as possible about a resource based on its identity. The more dependencies a piece of software has on particular constraints and inferences, the more fragile it becomes to change and the lower its generic utility.

<noah> I think I've gotten near consensus to drop 2.2, which is fine with me.

Ed: I disagree with WebArch on the issue of ".jpeg" being assumed image/jpeg. If it is OK to ship an exe and call it .jpeg that is asking for a problem on a users system in which a user opens a .jpeg thinging it is safe when it isn't.

NM: There is reasonable case when you server XML source as an example as text/plain, when it is clearly XML. It should be presented as text/plain.

TVR: If the content-type is there in the MIME headers, then it should be respected.

<noah> Ed: I think that pfishers are directly affected by this finding. They send things that end in .jpeg that are really executables.

<noah> Ed: email has URI that ends in .jpeg, but serves an executable (I.e. media type says executable)

Ed: problem case is that that a spam email which poinst to foo.jpeg and the user looks at the jpeg to see that it seems safe, and then they click on it.

NM: The phishers are not reading the good practice notes,
... People serving URIs should not mislead people in what is in the URI.
... In 2.1 we talk about a browser giving a warning that the content type doesn't match the local conventions for file extensions.

<DanC_lap> I'd like us to accept this contingent on Noah finishing his editor's TODO list to the satisfaction of, say, Ed.

[Consensus to delete 2.2]

<noah> Raman felt this was clunky: The first question is focused on people and software acting in the role of or on behalf of a URI assignment authority (authorities) for URI assignments within the scope of that authority.

<noah> Good Practice: URIs intended for direct use by people should be easy to understand, and should be suggestive of the resource actually named.

<noah> Mary is annoyed, because the URI is both difficult to remember and hard to transcribe accurately. She guesses that the authority has assigned this URI for its own convenience

<noah> rather than for hers

NM: When I am given a URI for a printer, one which is long and designed for good management and I am happy, as a consumer.

Ed: We are saying that long URIs are good for machine-machine or HTML, but bad for the side of a bus.
... Is it a good practice to deliberately obscure the metadata in URIs to stop people inferring stuff from it?

<noah> From section 2.8: Good Practice: URI assignment authorities should not put into URIs metadata that is to be kept confidential.

<noah> Bob would not have had to guess the Boston weather URI if the authority had documented its URI assignment policy. Assignment authorities have no obligation to provide such documentation, but it can be a useful way of advertising in bulk the URIs for a collection of related resources. For example, the advertisement might have read:

<noah> From section 2.4: Bob would not have had to guess the Boston weather URI if the authority had documented its URI assignment policy. Assignment authorities have no obligation to provide such documentation, but it can be a useful way of advertising in bulk the URIs for a collection of related resources. For example, the advertisement might have read:

Ed: Concern that penultimate paragraph of 2.4 allows Bob to write software .

Noah: Well, in this case it is justified by the existence of the HTML or XML form.

[discussion of the extent that having received the form from the resource authority allows software to be written to get at the same URIs the form would access.]

<DanC_lap> PROPOSED: to accept http://www.w3.org/2001/tag/doc/metaDataInURI-31-20060609 contingent on Noah finishing his TODO list to the satisfaction of ?WHO

?WHO -> Ed

RESOLUTION: to accept http://www.w3.org/2001/tag/doc/metaDataInURI-31-20060609 contingent on Noah finishing his TODO list to the satisfaction of Ed.

<DanC_lap> ETA 11 Aug

CURIES

HT: There is a question of what is the short syntax

There is the question of what it represents. For QNames it is a pair of a URI which should be absolute and a localname.

DanC: Webarch says you must map that to a URI

HT: This question is binding: How do you establish the binding of prefix to URI? In XML that is well defined.
... There are ways to do it in xpointer, n3, qt, and sparql.
... Fourth question is stability of the use of these in XML content: the connection between binding and use is not preserved by for example prefix renaming, as you don't know what to rename.
... Certainly, QT in schema aware mode does know what is a QName. It will synthesize a prefix, and make sure it is properly bound.
... These 4 questions apply to both QNames and Curies.
... We can use them to compare the schemes?
... We established at the AC meeting session that the semantics of CURIES are an IRI.

Tim: It is a pain sometimes that XML namespaces have to be absolute. CWM has a flag to turn this off, and we use it quite often, so the IRI can in these cases be relative.

HT: There is an argument from the stability question to say that the binding mechanism should be different... if one uses ones own binding system, then you don't suffer this but you suffer other things.
... The most common form of the answer to q1 is like [ prefix ] : localname
... The requirements are:
... Allowing IRIs of regular relationship to one another which share much of their starting string be expressible easily.
... This led to a borrowing of QName syntax.

For Q3, the RDF/A binding for example allows xmlns binding or RDF/a binding or both.

scribe: There is for NewsML (nor for RDF/A) a requirement to be able to start with a zero, but Misha seems to see that it can be done in the mapping: that the localname will start with a zero but the fragid, will not.

Danc: It is questionably a requirement -- Misha would like it but it isn't the case that he says that they need NewsML back-compatibility.

HT: Mark Birbeck is an RDF/A person

DanC: He is under contract from NewsML.

TVR: That doesn't mean they are the same ... MarK has been working on RDF/A for years.

HT: Norm and I initialy responded (speaking probably more or less for Core) that if it is so like a QName that it ought to be a QName
... but in this case it isn't: the semantics are quite different and so the syntax should be.

TVR: We used them for roles also. Bound by xmlns, In XHTML and implemented in Mozilla, but then people wanted it in HTML too.

HT: See also other shortname issues:

- WAI roles

- microformats

- XPointer schemes

- EPR -> URI

Microformats are not using namespaces at all -- they are like a counterexample.

We said that to reproduce EPR functionality with URIs was to have some kind of QName in the attribute names for the ?query string in the URI.

Noah: The prefixes are causing trouble -- it is much easier to encode full URIs within URIs.

<noah> I said something close but just a little different. I really was just reminding ourselves as we consider successive use cases to briefly ask whether using prefixes of any sort are the best tradeoff.

<noah> I do think that in the majority of cases on the table for discussion, prefixes >will< emerge as at least defensable and probably desirable. I was really just saying it's worth doublechecking.

Tim: The starting with a digit problem is a major issue, major clash between architectures.
... The binding and stability of the mapping is an old issue from the fact that XML does not have an integral QName system in the first class place in the syntax. This problem will not go away (before YML) but it can be moved from place to place, which is not a good idea in general.

HT: Stuart considered double colon. You can imagine using hash. There is a question of how to know in a random document which things are CURIEs. Some people (the rdf/a spec) has a square bracket mechanism inside an HREF. In NewSML you don't distinguish -- you always us CURIES.

NM: Consistent patterns are nice for grepping.

HT: In HTML4, IDs were not restricted to be name tokens (maybe)

Tim: There s a connection that anchors have to be IDs, that element names are the same production, and fragids are all localnames.

If you change one then you have to decide which other to change.

HT: Maybe: Just change ID, which also changed the fragids for XML and XHTML, and allow a new concept of curie which is a nmtoken followed by this new production.
... Lots of people have asked the question of why the localnames can't start with a number

Tim: But now, RDF has agreed to use the same production, and now alternative serializtions of RDF such as N3 and SPARQL really use the fact that names do not start with a number: a number starts the numeric literal syntax.

[ADJOURN for LUNCH]

CURIEs (continued)

[Scribe for afternoon is Noah]

HT: Take it up a level. What's the TAG issue? For which aspects if any should we be involved?

DC: Not clear that content of the design is necessarily raising architectural issues. To some degree we're positioned as the bridge between different concerned groups.
... As far as I'm concerned, each language can have its own way of abbreviating URIs. There seems to be a request here for a uniform mechanism across languages.
... Seems like a big coordination problem. Not convinced that such coordination is worth tackling.

TBL: Risk is that people start doing things anyway.

NM: Dan, are you mostly worried about the coordination issues, or do you think that any one of the proposals is badly broken?

DC: Mostly the former. I have some concerns that the proposal in RDF-A to change the rules for <a href=""> is very troubling, but that's not specifically what we're discussing here anyway.
... What about attribute value templates?

HT: That's an XSLT issue only.
... You're probably right to be more worried about square braces in <a href> than {} in XSLT.

DC: Right. Each format can choose its own mechanism.

NM: Do we know a use case why they should all do it the same way?

DC: Not obviously.

HT: There's a learning curve issue. Learn it once, you're a step toward learning to use it in other contexts.
... There are some differences of detail, but most users don't care.
... Net, net for me is that I think it's unfortunate that they chose the same separator character. That said, my objections went way down when RDF-A agreed to use the existing namespace binding mechanism to drive that syntax.

DC: I don't see any TAG members strongly advocating a particular shared solution here, but Tim and I did tell Misha Wolf that the TAG would put some time into this.

<DanC_lap> looking at http://lists.w3.org/Archives/Public/www-tag/2006Jun/0048.html

From that email:

"As I understand it, IPTC has a whole bunch of codes... collections of codes, in fact. Vocabularies, I gather. The goal is a compact syntax to encode a code within a vocabulary, such that you can get from this compact syntax a URI for the code within the vocabulary and for the vocabulary itself."

"Some of the codes start with digits. We suspect (though we're not certain) that vocabularies are homogeneous in this respect: within a vocabulary, either all the codes start with a digit or none do."

DC: My email sketched some options:

Option A. Have a syntax for binding, say, sic: to
http://sic.org/vocab1# and use sic:0070 for a code. To get a URI
for that code, concatenate them.  http://sic.org/vocab1#0070 . To
get a URI for the vocabulary, concatenate them and then strip off
the fragment: http://sic.org/vocab1 .  Similarly, bind, say,
iata: to http://iata.org/airports# and let iata:LGA expand to
http://iata.org/airports#LGA and then to get the vocabulary,
strip off the fragment http://iata.org/airports.

The sic:0070 short-hand does not match XML/XPath QName syntax, so
you can't use it in RDF/XML. You can't even make up a QName for
the URI http://sic.org/vocab1#0070 so you simply can't use it as
a property name in RDF/XML. (The example of a SIC code is not
something that you're likely to want to use as an RDF property
name

DC: Oops. I've gone from discussing requirements to discussing design options.
... Note that in option A, you bind the prefix to something other than the vocabulary URI.
... I.e. because you bind to concat(vocabURI,#)

HT: I claim that all that's needed is that the vocabulary IRI is recoverable from the IRI for any particular code.


Option B: Bind sic: to http://sic.org/vocab1 and use sic:0070; To
get a URI for that code, concatenate them with a # between:
http://sic.org/vocab1#0070 . To get a URI for the vocabularly,
look in the binding, and get http://sic.org/vocab1 .

Option C: Like A, but for any codes that don't start with an XML
name start character, put a _ in front of it before you use it in
any of these web technolgies. So sic:_0070 is the short syntax,
http://sic.org/vocab1#_0070 is the URI for the code, and again,
to get the URI for the vocab, strip off the fragment:
http://sic.org/vocab1 .  Now we can use the short syntax as a
QName in RDF/XML.

In Option C, the IATA stuff is the same as in Option A: bind
iata: to http://iata.org/airports# and let iata:LGA expand to
http://iata.org/airports#LGA and strip off the fragment to get
the vocabulary and get http://iata.org/airports .

There might have been some other options that I've forgotten.

NM: So, neither option A nor B work in XML, in the sense that neither does anything to avoid a leading numeric where a QName prohibits.

HT: I think Misha later expressed some comfort with a variant of option B, in which the specific URI is concat(vocabURI,#_,code).

<DanC_lap> Misha's msg with #_ option http://lists.w3.org/Archives/Public/www-tag/2006Jun/0049.html

DC: Note that Misha wants the literal text to NOT have the "_", but to infer it during the concatenation, as this helps things like Google searches work. Hmm, is it really true that in the situations you transfer to a Google search, you aren't in a position to strip the "_"? Not sure.

HT: Yes, if you try it, Google doesn't give same answer for _000XX.

TBL: But one reason Google doesn't do much with these codes, is that the "_" forms aren't out there.

NM: Right and the crawlers might eventually discover not only the "_", but also the relationship between the two forms.

<DanC_lap> Mark B enumerates CURIE-like things... http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005Nov/0049

HT: Mark Birbeck says something about QNames that I believe to be mistaken, specifically:
... "You see, I am proposing a *positive* solution, because my proposal *reserves* QNames for what they really are (a way of specifying namespace-qualified elements and attributes). For those situations where we want to abbreviate URIs, my proposal suggests using something with a different name (CURIEs) and making it explicit that this is what we are doing."

<DanC_lap> [[

<DanC_lap> We have XPath

<DanC_lap> functions using 'QNames', XML Schema datatypes using 'QNames', alternative

<DanC_lap> XForms appearance hints and submission types using 'QNames'...RDF/XML using

<DanC_lap> 'QNames'...SPARQL using 'QNames'...and so it goes on.

<DanC_lap> ]]

HT: I do agree that his note includes a useful list.
... I think he might have softened his disagreement on this a bit.

DC: Actually the use of QNames in RDF predates their use in XML Namespaces.

TBL: Yes, indeed it was a requirement going into the XML Namespaces work.

TVR: Some namespaces assigned in the past don't end in either / or #.
... This causes a problem when you use concatenation to build other URIs from them.

HT: People use the term QName to refer to, at different times: (1) the short syntax; (2) the XML schema datatype, which has a lexical and value space; (3) as shorthand for expanded names.

TVR: Is there a TAG question of making sure people have good names for things.? See, for example, NMTOKEN.

HT: Right, but it is the attribute type from the SGML DTD language.

TVR: Some of these technologies are touching a lot of people.

NM: Tradeoff. You want to be sure that people can get started without getting hit over the head with a glossary with 1000 terms in it.

TBL: Don't we do this in the arch document? Why are we talking about this?

NM: Well, Raman made a specific proposal that the TAG invest in the meta issue, which is encourging everyone else to more carefully define their own terms. I was responding to that proposal.

TBL: If the names with 0's get used, then RDF can talk to them as subjects and objects, or can use full URIs, except for the predicate. (Scribe is not sure he got that quite right.)

<DanC_lap> (looks right)

HT: Are there constraints on the fragment identifiers in RDF? I.e., we know that MIME types constrain fragids. Does RDF itself, as opposed to the XML serialization, make any assumptions?

TBL: It makes no assumptions about fragids per se at all.
... Strip off back to the #. On good days, the document it refers to will indeed contain information about the secondary resource.

HT: So, test.rdf#3_323zcvczxv may or may not be valid?

TBL: Well, the URI RFC says it is, but there may indeed be trouble when you try to look it up.

HT: It's not because there can't be an ID of 3_xxx, it's because the RFC constrains the BNF of the media type.

<DanC_lap> er... not "of the media type" but "of the fragment syntax" is what I heard HT say

TBL: Why are we talking about this?

HT: I got an answer to my substantive question, which is that RDF does not constrain the fragid syntax.
... Aren't there graphs that can't be serialized?

TBL: Some people think that's a bug in the serialization spec.

DC: Why are we debating this?

HT: Because we want to know if changing what an ID is would change RDF.

NM: Which proposal are we debating here?

HT: I thought we were proposing to change the rules for attributes of type ID.

NM: Are we serious about changing XML not to have NMTOKEN? I don't think it will fly given the amount of XML software out there. This is just like XML 1.1, in that it would have been perfectly reasonable if done in XML 1.0, but is not reasonable now given amount of deployed software.

??: (Scribe believes this was copied from an email being discussed)

Considering from Mishas note (http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005Nov/0049):

The option I favour is:
  vocabIRI          = http://sic.org/vocab1
  prefix            = sic
  suffix (aka code) = 0070
  CURIE             = sic:0070
  construction rule =  & "#_" & 
  codeIRI           = http://sic.org/vocab1#_0070

HT: N3 will not interpret sic:0070 the way CURIEs does.
... So, NewsML and CURIE would have different rules for mapping this to URI?

TBL: Would like to consider conditional rules.

<DanC_lap> how you'd have to write the sic:0070 example from Misha's "what I favor":

<DanC_lap> @prefix sic: <http://sic.org/vocab1#>.

<DanC_lap> sic:_0070 dc:description "abc".

TBL: If really pushed, we could push N3 to put in a conditional construction rule.

<tvraman> someone just posted a note on www-tag showing the use of - or . as the separator char (ERDF)

HT: Are numerics really the only characters Misha needs that break NMTOKENs? Are there other characters in the existing content that would cause trouble?

<DanC_lap> http://www.w3.org/TR/rdf-sparql-query/#rNCCHAR1

<timbl> DanC; The DAWG group made arbitrary decisions about the regexp for mntokens

<timbl> in sparql

<timbl> Tim: In N3, we were careful to follow what XML did.

<DanC_lap> turns out I misspoke; I was reporting on a bad dream of mine, not real life ;-)

<timbl> NW: The sparql production copies eactly the production in XML 1.1

<ht> http://www.w3.org/TR/xml11/#NT-NameChar

<ht> http://www.w3.org/TR/xml11/#NT-NameStartChar

<DanC_lap> http://www.w3.org/TR/2004/REC-xml11-20040204/#NT-NameStartChar

NM: The diagram on the board gets me in the ballpark, but I'm not following its implications quite well enough to understand either the goals for interop between CURIEs and N3, or to understand the degree to which any one branch of that diagram meets those goals.
... As your scribe, I need you to either explain it to me, or scribe it yourselves.

HT: Maybe we need to suggest that the conditional concatenation in CURIE does NOT add a # if the vocabURI already has one?
... Not sure whether "/#" is ok or not?

TBL: Well, it's very bizarre. Should normally be # or /. With / they should but very often don't respond with HTTP 302.

HT: On balance, I think the communities are far enough apart, and the pressure for solutions on the N3 side is sufficiently low, that asking Misha to change his conditional may not be worth it.
... Premature optimization.

TBL: Some of this we can't change later.
... Conditional would be "only if number and only if no #"
... Clarification. Conditional is "If numeric, add a _; if no # and no /, add a #".
... Do we need to worry about anything other than NewsML? RDF-A?

HT: We have a list on the whiteboard, I.e. WAI roles and microformats?

DC: I don't think Microformats are going there.

NM: We breaking soon?

VQ: Need to wrap up CURIE conclusions.

TBL: Well, we've made some good progress in improving out own understanding.

We decided to draft a response for consideration by Misha and others reading the ongoing email thread.

That response has been sent and is at: http://lists.w3.org/Archives/Public/www-tag/2006Jun/0057.html

The key points are:

In today's discussion[1], we realized airport:LGA in NewsML 2
wouldn't work like airport:LGA in, say, SPARQL. We also
realized that if an RDF user copied a namespace URI
ending with a # to a NewsML document, that construction
rule would result in a bogus URI with two ##s.

What do you think of this...?

construction-rule =
   if vocabURI ends with a #, s1 = '' (empty string) else s1 = '#'
   if code does not start with a name-start character, s2 = '_' else s2 
= ''
   return  + s1 + s2 + 

See the email for more detail.

Note that Ed Rice left for the airport during the CURIE discussion.

***AFTERNOON BREAK****

Cleaning up Actions on metadatainURI-31

See pertinent section of today's agenda: http://www.w3.org/2001/tag/2006/06/12-agenda.html#L170

Action DO, accepted on 21 Jul 2003: Send rationale about why WSDL WG wants to peek inside the URI. is withdrawn.

NM, accepted on 30 May 2006: Produce new version of The use of Metadata in URIs is DONE

<scribe> ACTION: Noah to produce final draft of metadataInURI-31 by 11 August [recorded in http://www.w3.org/2006/06/14-tagmem-irc]

Issue abstractComponentRefs-37

VQ: We have a few very old actions. They are

1. DO, accepted on 20 Oct 2003: Revise draft finding based on comments at 20 Oct teleconf.

2. DO, proposal on 3 Nov 2003: IJ published this from material sent by DO to IJ privately on 30 Oct 2003.

DO: I'd just close them.

VQ: We have a very old document by Dave at http://www.w3.org/2001/tag/doc/abstractComponentRefs.html and the two issues.
... Dave, what do you propose to do?

DO: Nothing.

HT: Maybe we should come back to this iff the Schema WG issues a Schema Component Designator Document. There's some reasonable chance they will.

The two actions listed above are DONE.

endPointRefs-47

VQ: We seem to have an issue open DO, accepted on 4 Oct 2005: draft something indicating the issues with EPR and potential solutions.

DO: I think I did that.

TBL: We have put a lot of effort into addressing this issue, have held meetings with concerned parties, and feel that further work at this time would not be cost effective for the TAG. Therefore we are marking Dave's action as WITHDRAWN.

Issue RDFinXHTML-35

VQ: Last discussion was in Dec 2005. Dan says it remains on my "hope to do something" pile.

DC: There's a GRDDL working group charter being reviewed by the Advisory Committee.
... RDF-A has issued working drafts.
... This also relates to issue fragmentInXML-28

TBL: Right, this has to do with content negotation, and resolving a fragment ID.
... The other thing is that you have mixed namespace stuff, and the anchor resolves into the compound document.

DC: Yes, I understand. No, I don't have the energy to discuss right now.

NM: (actually said this earlier and got behind in scribing) I'm not convinced the conneg one is XML-specific.

Issue namespaceDocument-8

<scribe> Pending actions:

1. NW, accepted on 12 Jul 2005: Follow up on noah's message on ns name. Reconfirmed on 10 Jan 2006

2. HT, accepted on 6 Sep 2005: Track progress of #int bug 1974 in the XML Schema namespace document in the XML Schema WG

3. NW, accepted on 10 Jan 2006: Propose to Jonathan Borden that he changes to using a file of Natures

NW: #1 and #3 are continuing, I have to get to them.

HT: #2 is pending

Telcon Scheduling

VQ: Noah, Norm, Tim and Dave have sent regrets for next week.

DC: Let's not meet.

RESOLUTION: No telcon on 20 June 2006

VQ: How about the 27th? I see regrets from Tim.

NW: Regrets from me too.

RESOLUTION: We will have a telcon on 27 June 2006

TVR: I will have a draft of my finding in time for that.

VQ: We should also have Ed's password in the clear.

<Norm> We'd like to thank the University of Massachusetts, the Computer Science Department, and its staff for providing facilities for this meeting. In particular, we'd like to thank Bruce Croft, Claire Christopherson, Steve Cook, Victor Danilchenko, and Barbara Sutherland for their assistance.

VQ: Thank you to our host, Norm.

***Adjourned***

Summary of Action Items

[NEW] ACTION: Noah to produce final draft of metadataInURI-31 by 11 August [recorded in http://www.w3.org/2006/06/14-tagmem-irc]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.126 (CVS log)
$Date: 2006/06/28 12:57:52 $