- From: Ralph R. Swick <swick@w3.org>
- Date: Tue, 20 Sep 2005 12:09:50 -0400
- To: public-rdf-in-xhtml-tf@w3.org
The [1]record of today's telecon is now available for review.
[1] http://www.w3.org/2005/09/20-swbp-minutes.html
A text snapshot of revision 1.2 $Date: 2005/09/20 16:04:14 $ follows.
----
SWBPD RDF-in-XHTML TF
20 Sep 2005
See also: [2]Agenda, [3]IRC log
[2] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005Sep/0015.html
[3] http://www.w3.org/2005/09/20-swbp-irc
Attendees
Present
Ralph, Steven, Jeremy, Mark
Regrets
(Ben)
Chair
Ralph
Scribe
Ralph
Previous
[4]2005-08-16
[4] http://www.w3.org/2005/08/16-swbp-minutes.html
Contents
* Topics
1. Convene, Review records
2. Issues walkthrough
1. QNames in href and about
2. bnodes
* Summary of Action Items
_____________________________________________________________
Convene, Review records
Ralph: only TF participants who are WG participants are expected to
attend the [11]Galway f2f but I expect that if Mark and Steven were
interested in attending we wouldl make them welcome
[11] http://sw.deri.org/2005/07/swbpd/
[12]Previous meeting was 2005-08-16
[12] http://www.w3.org/2005/08/16-swbp-minutes.html
Issues walkthrough
-> [13]issues list
[13] http://www.w3.org/2001/sw/BestPractices/HTML/2005-current-issues
QNames in href and about
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> [14]Mark's compact URI proposal of 19 July
[14] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2005Jul/0019.html
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
bnodes
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
[15]http://www.w3.org/2005/07/26-swbp-minutes.html#action10]
[CONTINUES]
[15] http://www.w3.org/2005/07/26-swbp-minutes.html#action10
<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
[16]http://www.w3.org/2005/07/26-swbp-minutes.html#action06]
[CONTINUES]
[16] http://www.w3.org/2005/07/26-swbp-minutes.html#action06
ACTION: All take a serious look at Mark's [$1\47]bnode proposal
summary [recorded in
[17]http://www.w3.org/2005/07/26-swbp-minutes.html#action07]
[CONTINUES]
[17] http://www.w3.org/2005/07/26-swbp-minutes.html#action07
ACTION: Ben to put together the "ACID" test for XHTML2 RDF/A [recorded
in [18]http://www.w3.org/2005/07/26-swbp-minutes.html#action02]
[CONTINUES]
[18] http://www.w3.org/2005/07/26-swbp-minutes.html#action02
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> [19]www.iptc.org
[19] http://www.iptc.org/pages/index.php
<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
Summary of Action Items
ACTION: All take a serious look at Mark's [$1\47]bnode proposal
summary
[recorded in http://www.w3.org/2005/07/26-swbp-minutes.html#action07]
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]
ACTION: JJC to review rdf concepts and fragments
[recorded in http://www.w3.org/2005/07/26-swbp-minutes.html#action10]
ACTION: Mark to check edge cases of inheritance in RDF/A
[recorded in http://www.w3.org/2005/07/26-swbp-minutes.html#action06]
[End of minutes]
_____________________________________________________________
$Date: 2005/09/20 16:04:14 $
Received on Tuesday, 20 September 2005 16:20:53 UTC