Ralph: only TF participants who are WG participants are expected to attend the Galway f2f but I expect that if Mark and Steven were interested in attending we wouldl make them welcome
Previous meeting was 2005-08-16
-> issues list
Steven: add bnodes issue to current-issues
... from Hypertext CG, the suggestion came (from Bert Bos perhaps) to invent
a URN to represent QNames
Mark: we discussed this before. IPTC folk were
not impressed by this solution
... IPTC wants to keep the identifiers as short as possible
... ideally they'd like to be able to carry forward their current identifiers
unchanged
... ease-of-use is the foremost concern
Steven: how can we know what really will be barriers to adoption?
Mark: we'd need to register a naming authority for URN
Steven: could do urn:iptc:...
Ralph: so the RDF community would like IPTC to run a resolution service that essentially reinvents the http: resolution service
Jeremy: there would also be an issue with name
collision
... qnames allow relatively long URIs to be used in a concise way
... whereas URN or any other URI scheme has to deal with the fact that you're
sharing a global identifier space hence URIs need to be long
Mark: I came to the conclusion that we
shouldn't touch qnames; that it's naughtly to use them in this way to
represent every possible URI
... so rather than trying to make URIs and QNames co-exist in the same
attribute and to loosen the syntax constraints on QNames, I proposed a new
datatype CURI -- conmpact URI
... doesn't make any clames to be like a QName
... have discussed this with IPTC and they are supportive
... CURI syntax similar to common Wiki usage
... we would need two attributes to support such a mechanism; i.e. not
squeeze both URI and QName into a single attribute
<Steven> Mark's compact URI proposal of 19 July
Ralph: has this proposal been discussed in any other forum?
Steven: no, the HTML WG would likely think it
outside their scope
... it could go to the Hypertext CG
... Bert Bos' comment came when I mentioned the CURI idea
Jeremy: URNs do involve some sort of
registry
... a compact URI scheme could have a short scheme component followed by a
string to be substituted according to some application context
... could give the power of QNames without the syntactic overhead of it being
an XML thing
... feels do-able but it would be a stretch to get a new URI scheme
Steven: CURI doesn't propose a new URI scheme but rather a new datatype that is interpreted in a new way to produce a URI
Mark: CURI doesn't solve the problem of making
URIs and QNames coexist
... I'd like to see CURI along with square brackets used
... '[ ]' would denote CURIs so that legacy code stays the same
Steven: perhaps this could be added in XHTML2;
we're in control of our own datatypes
... as long as URIs are a subset it is backwards compatible
... and we add an interpretation rule for the attribute value enclosed in
[..]
Mark: there may be a precedent for something
like this; an attribute that can take one of 2 values
... IPTC might not be happy even with square brackets
Jeremy: could do just a leading character, e.g. '^'
Mark: note that a CURI starting with a ':' is one without string substitution, so any URI becomes a CURI with a ':' prefix
Steven: as long as old content looks the same and is interpreted the same we can add rules for new syntax
Jeremy: all the URI schemes in the registry
could be defined as builtins
... any new URI schemes could be required to follow additional contraints
<jjc> xmlns:skype="skype:"
Steven: I think we're best-off if we say only that new content is indicated in a different way
Jeremy: I've recently been testing URI code and
have found that it is difficult to write an illegal URI
... it's surprisingly tricky to break the URI syntax
Mark: [our product] uses '{}' in some URIs and
only recently I discovered a URI parser that throws these out
... if we went with Jeremy's leading-character proposal it could be viewed as
a new class of URI schemes
Jeremy: no, better to make the leading character indicate datatype
Ralph: do you think IPTC would be more receptive to this leading-character proposal than to additional attributes?
Mark: perhaps so
<Steven> I think the colon looks good as initial character: href=":iptc:12345"
<Steven> It also suggests an empty scheme
<jjc> ":iptc:12345" is not a URI and hence is appropriate as a compact URI format
Mark: looking at the examples in my 19 July
email, the CURI proposal effectively codifies some existing practice
... whereas a new leading character is new practice
... e.g. anyone who uses joseki will be comfortable with joseki: being
interpreted as a substitution
Jeremy: I'm not advocating leading-character
versus surrounding '[ ]
... strongly; just describing alternatives
Jeremy: adopting the direction of the CURI idea; we could say that '_' is one of those schemes that denotes bnodes
Mark: we still need to identify the node
Jeremy: the ID suffices to identify the bnode
<jjc> :_:1 vs [_:1]
<Steven> I think href=":_:foo" looks fine
<MarkB_> I think it looks too much like a 'scheme'.
ACTION: JJC to review rdf concepts and fragments [recorded in http://www.w3.org/2005/07/26-swbp-minutes.html#action10] [CONTINUES]
<jjc> Jeremy said that rdf:about and rdf:href with bnode ":_:aa" is sufficient
ACTION: Mark to check edge cases of inheritance in RDF/A [recorded in http://www.w3.org/2005/07/26-swbp-minutes.html#action06] [CONTINUES]
ACTION: All take a serious look at Mark's [3]bnode proposal summary [recorded in http://www.w3.org/2005/07/26-swbp-minutes.html#action07] [CONTINUES]
ACTION: Ben to put together the "ACID" test for XHTML2 RDF/A [recorded in http://www.w3.org/2005/07/26-swbp-minutes.html#action02] [CONTINUES]
Mark: IPTC has a big meeting the end of October
(week ending 29th)
... they'll be discussing their metadata syntax there
... I have a deadline of next Monday to produce a new RDF/A draft
<jjc> www.iptc.org
<Steven> 24 - 27 Oct 2005 IPTC Autumn Meeting in Milan (Italy)
Ralph: can you share that document with the TF?
Mark: yes, I believe so. After Monday I will send that document or an edited version to the TF
next meeting: 27 Sep, 1400 UTC