See also: IRC log
ER: No call July 4
... We will have a call 11 July, Vincent will chair.
ER: We have multiple sets of draft minutes for F2F. Approve separately?
<DanC> meeting page: http://www.w3.org/2001/tag/2006/06/12-agenda.html
NM: Usually we have integrated directory page or otherwise combined. Suggest we not approve until done.
DC: I can abstain if others like them.
NM: I've read some, not all. Can let it go.
RESOLUTION: Minutes of Amherst F2F are approved.
<scribe> ACTION: Vincent to post minutes of Amherst F2F, with some sort of main page linking the pieces. [recorded in http://www.w3.org/2006/06/27-tagmem-irc]
Note that we are joined for this discussion by Steven Pemberton (SP) and Misha Wolf (MW)
SP: What's the goal of this discussion?
ER: We had a F2F meeting. Draft minutes (just approved) linked from today's agenda.
<DanC> (found the relevant part of the minutes http://lists.w3.org/Archives/Member/tag/2006Jun/att-0049/June142006.html#item02 )
MW: OK to set some organizational context?
<Ed> ipdc : www.ipdc.org
MW: About a year ago we (International Press Telecommunications Council - IPTC) asked W3C to collaborate with us on NewsML2. Meeting was 8 July 2005.
<Steven> iptc
<Steven> www.iptc.org
<DanC> W3C/IPTC meeting, 8 July 2005, London
MW: We were particularly interested in CURIEs, and are now trying to complete our spec.
... With a year having gone by, we're wondering what's happening. Trying to give a push.
... Note that we are not W3C members, so don't have access to member space.
... Want something that would help not just us but other parties too.
... There was the W3C AC Meeting in Edinburgh
<Steven> TAG panel at the AC meeting
ER: How should we proceed?
DC: Tried email, didn't work.
SP: Background: this work has emerged from the RDF in XHMTL task force.
... We are attempting to create a method of writing RDF triples in XHTML, using what looks to the author like traditional HTML means.
... HTML author understands as HTML, generalized so you can extract RDF triples.
... Since subjects, predicates, and many objects are written as URLs, there is need for short form.
... Obvious way was QNames, but they don't quite do it due to syntactic restriction, which prevents representation of certain URLs.
... Therefore decided to use what we called Compact URIs (CURIEs). Semantics is to look up prefix and concatenate.
... Discussed other syntax. There were tradeoffs.
... Decided on QName-like syntax.
... Then started coordination with IPTC, which was already using similar mechanism.
TVR: we needed something similar for role="...".
... Communities such as WAI can define roles. Thus, a structured two-part namespace is useful.
... Can define roles in RDF, if you like.
HT: Based on email, there seem to be at least 2 constituencies and 2 proposals.
... (1) IPTC and NewsML as captured in email from Misha.
... (2) RDF-A working draft.
<DanC> (er... it's in an RDFa working draft? Steven's recent msg said the HTML WG's CURIE spec is not released)
HT: Most importantly, there appear to be two distinct requirements:
... Requirement #1: Abbreviate URI references to short names.
... Requirement #2 (just mentioned by Steven): abbreviate any set of URIs that share a prefix.
... Not surprising we get different proposals, given different requirements.
SP: A predicate can be any URI.
HT: My understanding is that RDF either uses full URIs, in which case there is rarely any systematic assignment of URIs that would promote prefix sharing, vs. those that use anchors, in which case you have a clean split at the anchor.
SP: The # bit?
HT: Well, some use # and some don't.
... Consider your dc.creator. My point is that I've never seen anything other than short names to the right of the colon.
<Zakim> ht, you wanted to identify differing requirements
HT: Thus it seemed to me that asking for an arbitrary break point may be an unnecessary expansion of the requirement scope. Is there a motivation?
SP: Don't recall how we got there. Do recall we had use cases. Would have to go back and check.
<DanC> (it's an acknowledged limitation of RDF/XML that it doesn't support some property URIs. http://www.w3.org/2000/03/rdf-tracking/#rdfms-qnames-cant-represent-all-uris )
TVR: Interesting point.
... Note that on servers, CGI-BIN etc. tend to split URIs at "/", not just at fragment.
... You're right that N3 and Sparql tend to use only the fragid
<ht> HST has never had a problem with abbreviating http://foo.xample.org/baz/mumble as x:mumble
<ht> HST is asking what the motivation is for abbreviating it as y:baz/mumble
<Steven> iptc certainly has iptc:12345
<Steven> which is not a qname
<Steven> but that was a simple use case for the need to compress URIs
<DanC> HST, one motivation is to be able to handle the case of http://acme.com/property/ , i.e. something that doesn't end in an XML name character
<ht> Steven, yes, that's why Misha has suggested, and others have likes, using _ in the concatenation
<Steven> but 12345 is not a shortname
NM: CGI does indeed split at non-trailing "/", but I'm not convinced that's motivational of a requirement for CURIEs.
DC: Client is only allowed to look at "#"
<ht> Steven, agreed, but on misha's proposal f:123 would expand to e.g. http://example.org/root#_123
<ht> if 'f' was bound to http://example.org/root
<Steven> Yes, but then you still need something more than a QName
NM: Well, URI RFC licenses inference of hierarchy.
TVR: Have to go in a minute.
HT: I'm not convinced we have a requirement for "a/b/c" in the right hand part.
TVR: Yes, you put that nicely.
... I would like to set direction for user communities.
MW: Not being in HTML or RDF groups, not sure exactly what they did.
... Still, I thought they might have been after capturing wiki practice involving ":"
... IPTC requirements are...
<raman> I'm leaving ... sorry to miss the rest of what should be an interesting discussion.
MW: (1) loosen NCNAME requirement to allow digits, though don't need "/" in right hand part.
... (2) do not want to use xmlns to declare prefix associations. We have our own mechanisms.
... Would like it if it were a more general mechanism.
DC: That's what confuses me. You seem to have enough constraints that sharing is a questionnable goal.
MW: Sharing is good if it's possible. If not, not.
... Seem that there are some slight variants on QNames out there.
... Risk that people try to claim these are the same, when in fact there's not.
DC: Agree there's some confusion & pain. Not clear to me we can do much better.
SP: We're trying.
DC: But just between HTML and NewsML2, I haven't seen one proposal that makes everyone happy.
SP: I'm not quite sure why TAG is involved just yet, as we're still working on designs.
<ht> Issues: 1) simple (for some value, not necessarily NCName, defn of simple) vs. arbitrary suffix
<ht> ... 2) xmlns to bind vs. other binding
<ht> ... 3) One story about concatenation or many;
<ht> ... 4) unitary semantics or compound
MW: Leave it for now?
SP: still working on it.
... Don't really understand where the architectural question comes in.
HT: You're right, there's no a priori issue.
... Speaking for myself. As far as I know, this came to TAG because XML core was concerned about the possible emergence of something confusingly similar to, but not quite the same as QNames.
... That is an architectural principle.
<DanC> (seems more like a usability issue than an architectural issue, but still relevant to the TAG as a cross-WG mediator)
HT: Seems to me that different CURIE design choices are likely to determine whether QName syntax or shortname syntax is easier, harder (or the same) for people to understand.
<Zakim> noah, you wanted to probe whether TAG has any general guidance.
NM: No, Henry covered my concerns. Thank you.
HT: Also, some of us felt that href is pretty close to a de-facto architectural core of the Web at this point. Weren't convinced that changing allowed contents is a small thing.
<Zakim> ht, you wanted to ask about (4)
HT: I would like to ask a bit about clarifying what the goals are. See my IRC entries above. Want to talk about #4, I.e. unitary semantics or compound.
... To use schema terminology, if this thing were a type, would its value space be sets of pairs, or IRIs (I.e. strings constrained to BNF)?
... Seems to me there's been lack of clarity on value space of CURIEs.
... I understand Misha to say that NewsML badly needs it to be a tuple, but I understand it to be a different tuple than the one used for QNames.
... I understand that you want the value space for x:y to be the tuple:
... [[concat(head,tail)],[head]]
MW: We want people to be able to learn about each vocabulary, and each
term in each vocabulary.
... Pretty similar to namespaces, but Namespaces is a bit looser about construction rules (?) for individual terms.
... Consider ISBN vocabulary. The specific term in the vocabulary might be a URI you obtain using some construction rule.
HT: I think, Steven, it's fair to say that the value space for CURIEs is IRIs.
SP: Right.
<Zakim> noah, you wanted to mention different views of same value space
NM: I'm a bit less convinced than Henry that the way the values in the value space tuple are sliced is key; the main significance of the value space is that it successfully distinguish things that are different. Having done that, you can define functions to get the other things you need.
<ht> NM, good point -- and Misha may well care to distinguish http://foo.example.org/a/b_c arising from http://foo.example.org/a/ + b_c from the same IRI arising from http://foo.example.org/a/b + '_' + c
MW: Yes, but we have said that we all need different functions for different purposes.
NM: Well, there's still the question of whether the Web is better off with multiple functions from the same x:y syntax into IRI, or whether it's better to have distinct syntax to convey use of distinct mechanims. I personally am undecided on that important question.
ER: Do we want to leave it in this unresolved state for now?
DC: That does it for me.
ER: Thanks to our guests for joining us. It's been very helpful to learn more about your needs and motivations.
MW?: We'd appreciate review of the draft minutes.
When reviewing the draft minutes, Misha asked that the following be included. Since the scribe does not recall where in the above discussion Misha made this comment, it is being included here:
MW: In the discussion of construction rules, I mentioned that in addition to the: prefixIRI & "#_" & suffix approach, the IPTC is considering plain concatenation, using prefixIRIs ending with "/" or "?" or "#_". See: http://lists.w3.org/Archives/Public/www-tag/2006Jun/0112.html.
ER: Should we wait for T.V., who is not with us now?
DC: Who has the ball?
ER: T.V.
... OK, wait.
(added to agenda at Dan's request)
DC: Hmm, can this wait? Let me think...
<DanC> http://www.w3.org/2003/08/Workshops/
DC: Workshop is 12-13 July
<DanC> 12-13 July 2006
ER: Our next telcon is the day before.
DC: Is anyone from TAG going to workshop?
Silence.
DC: We've had discussions of how this info can be distributed, e.g. centralized like IANA vs. query service vs. federated query vs. client puts its own description URI in the queries.
... I'm struggling to figure out if all of these are all real possibilities or any ruled out.
... There's a risk W3C will be asked to run a giant server.
ER: Why can't we say "there are 10 formats".
... If we go down to "every single device" is that assuming.
<Ed> mobil group should look at this from a publishers/users perspective instead of every device perspective. Publishers CANNOT test to 1200 differant formats, we're lucky if we get 10 formats.
NM: Feels to me like some publishers will want details.
ER: HP isn't going to tailor
NM: But Napster or iTunes might want lots of detail on sound reproduction, independent of form factor.
ER: Good point.
<DanC> 12/13 July 2006
<DanC> Madrid, Spain
ER: Where is workshop?
DC: Madrid.
ER: I still worry that too much of this gets driven by device people, rather than content people.
NM: (said this earlier but didn't scribe it) Also, some publishers may want fine grain detail for bug fixes targeted to certain devices.
DC: Was hoping to get the TAG involved, but maybe that's not to be for now.
ER: Hard to see how we contribute in advance if we don't have access to the papers.
... Is it appropriate for us to ask for access?
DC: How would read?
ER: I would.
NM: I'll be out a lot between now and then, otherwise good idea.
DC: DaveO?
DO: No.
DC: Not critical mass.
... We may follow up individually, but not for now as TAG.
Adjourned.