See also: IRC log, previous 2007-06-28
ACTION: Ben make a scribe schedule [recorded in http://www.w3.org/2007/07/05-rdfa-minutes.html#action01]
ACTION: Michael add a test case that test for omitted @about [recorded in http://www.w3.org/2007/06/28-rdfa-minutes.html#action04] [DONE]
[see ref. to TC30 in Michael's
reply to the agenda]
ACTION: Michael correct TC15 title [recorded in http://www.w3.org/2007/06/28-rdfa-minutes.html#action05] [DONE]
[see Michael's
reply to the agenda]
ACTION: Michael create a .htaccess hack to make the test case identifiers resolve to something useful [recorded in http://www.w3.org/2007/06/28-rdfa-minutes.html#action01] [DONE]
[see Michael's reply to the meeting record]
ACTION: Shane investigate the @xml:base validation issue [recorded in http://www.w3.org/2007/06/28-rdfa-minutes.html#action02] [CONTINUES]
Shane: this appears to be harder than I thought
Ben: we expect xml:base to be used in HEAD ?
... to set the CURIE base URI?
Mark: yes, it should work with HTML base
ACTION: [DONE] Shane to correct DTD to permit RDFa attributes on the head element. [recorded in http://www.w3.org/2007/06/28-rdfa-minutes.html#action03]
ACTION: [DONE] Ben get further input from Creative Commons on @RESOURCE and @HREF [recorded in http://www.w3.org/2007/06/21-rdfa-minutes.html#action15]
-> the
Creative Commons take on @href everywhere [Ben 2007-06-27]
ACTION: Ben to figure out the RDFa-GRDDL-profile URI (at w3.org) [recorded in http://www.w3.org/2007/06/14-rdfa-minutes.html#action15] [CONTINUES]
Ralph: I'll take this one over from Ben
Mark: let's put @xml:base everywhere on our
syntax agenda; what does it mean for HTML ?
... it's no longer XHTML2-ish
... one possibility is to defer @xml:base everywhere to a future version
Ben: I'll add this to issues list
ACTION: Ben to look into Science Commons use case [recorded in http://www.w3.org/2006/12/11-htmltf-minutes.html#action04] [CONTINUES]
ACTION: Elias to send email to list with use case from IBM [recorded in http://www.w3.org/2006/12/04-htmltf-minutes.html#action10] [CONTINUES]
ACTION: Mark get input from Joost on @HREF everywhere [recorded in http://www.w3.org/2007/06/21-rdfa-minutes.html#action14] [CONTINUES]
Mark: I sent email to Joost today
ACTION: Mark produce more examples of applicability of n-ary relations from IPTC documents [recorded in http://www.w3.org/2006/10/23-htmltf-minutes.html#action08] [WITHDRAWN]
Mark: this is part of the reification discussion; let's defer it to the future
ACTION: MarkB to work rdf:label back into RDFa syntax when using @content [recorded in http://www.w3.org/2007/03/19-rdfa-minutes.html#action25] [CONTINUES]
Mark: this is more problematic than I first though too
ACTION: [DONE] Steven to put together sample XHTML2 doc with all mime type, etc. [recorded in http://www.w3.org/2006/09/19-htmltf-minutes.html#action01]
-> [RDFa] ISSUE 9: META and LINK in the body
Ben: if we remove LINK in the body then it feels to me we may need to have @href and @resource everywhere
Steven: I think it's a bad idea to depend on
META and LINK in the body
... everything that depends on this behavior we should find a different way
to do
Ben: if served as html+xml then FireFox no
longer repositions these to HEAD
... IE continues to do this, however
Ralph: this feels to me as something where we should not step on the base language
Shane: we have changed the content model of HEAD by saying META and LINK both accept content
Steven: yes, for XHTML2, and this is a good thing
Mark: IE does not move LINK and META in HTML
mode
... what it does do is treat META as a straight element with open and close
tags
... <META>text</META> is treated as 3 sibling nodes by IE
... so even if we do allow META in the body there is quirky parsing
... I've made this work in my parser but it is quirky
Shane: my change to HEAD content model is for XHTML1.1 -- let's not discuss XHTML2 here
Ben: should we change back to original content models for LINK and META and just add @property ?
Steven: I think it's good to permit LINK and META in body for XHTML2 but not for XHTML1.1
Ben: what about content of LINK and META? This doesn't seem very useful in this case
Shane: I don't understand what problem this was intended to solve, but LINK can contain LINK
Ben: since we're deferring reification, maybe
we can undo our changes to LINK and META content model
... we had a use case from Bob Ducharme with nested LINKs
... we could say this feature will only be available in XHTML2
Steven: if you want to put something in the HEAD and have marked-up content in META you couldn't do this
Mark: Bob's example was the IPTC use case of
wanting to say who made an assertion; this is reificiation
... the other use case for content in META is XMLLiteral
... since attribute content can't contain markup
PROPOSE: LINK and META appear only in HEAD with no changes to content model
[no objections]
ACTION: Ben to send to mailing list PROPOSE: LINK and META appear only in HEAD with no changes to content model [recorded in http://www.w3.org/2007/07/05-rdfa-minutes.html#action15]
Shane: I think this allows us to remove the whole "metainformation module" part of the spec
Steven: we say 'use the closest @about when
generating the subject'
... with special rules for META and LINK
... I guess those special rules now go away?
Ben: but we still want bnodes
... so some of the use cases are replaced by @rel without @href
Steven: this takes care of object, but not subject
Ben: can do the same with SPAN
<benadida> <div id="foo" rel="foaf:knows">
<benadida> <span property="foaf:name">Ben</span>
<benadida> </div>
Ben: in this example, @rel sets the subject because there's no @href
<benadida> <div about="#bar">
<benadida> <div id="foo" rel="foaf:knows">
<benadida> <span property="foaf:name">Ben</span>
<benadida> </div>
<benadida> </div>
Ben: this example means ...
<benadida> <#bar> foaf:knows <#foo>
<benadida> <#foo> foaf:name "Ben"
Ben: @rel without @href makes that node be the
subject; it would be a bnode if it didn't have @id
... later we can talk about what it means if the DIV had @href
Mark: agree with that interpretation
Ben: so this handles most of the cases where we
used META in BODY
... it becomes more important to relate the bnode to the document
ACTION: Ben summarize the state of @rel everywhere [recorded in http://www.w3.org/2007/07/05-rdfa-minutes.html#action16]
Simone: I prefer to not use META and LINK an all, I like approach of iRDF (fromer eRDF), so META is an EMPTY element and may create problems
Ben: as Shane points out, since CURIE spec is not done it's dangerous for RDFa to have it as a dependency
Mark: the choices are not CURIE vs QName but
CURIE vs. something unspecified
... look at SPARQL and RULEML
... there is a tendency towards using the [syntactic] concept of QName but
without the restrictions
... we either do the same thing; looks like a QName but new rules for how
they're defined
... I don't like to continue the misuse of QName
... QName is for defining elements and attributes in XML markup
<benadida> cc:attributionName
Ben: cc:attributionName can be expressed in
RDF/XML
... is this not really a QName, just looks like one?
Mark: it conforms to the syntax but out of
context it can't be a QName, because the purpose of QName is to define an
element
... so when it's used as a predicate in RDF/XML it's fine because it _is_
defining an element
Ben: can we punt to SPARQL and N3 and simply
say we're using the syntax the same way they are? And in XHTML2 clean it up
by defining CURIE
... we can say we'll use the same inconsistent view that others have
Mark: but SPARQL doesn't refer to QName
<markbirbeck> http://www.w3.org/TR/rdf-sparql-query/#QSynIRI
Steven: SPARQL calls these "prefixed names", not QNames
Mark: and there's a big red box noting that not all prefixed names are XML QNames
Ben: will we get into trouble by using @xmlns to define the prefixes?
Mark: this has been talked about a lot
... one suggestion is to say that @xmlns is only one way to define
prefixes
... could use a triple to declare a prefix; then LINK suffices
<ShaneM> (rel = curiePrefix)
Mark: alternative is to include @xmlns in our
vocabulary
... or, further, say 'given these attribute values, load these triples'; e.g.
well-known prefixes
Ben: I don't like the third option as it doesn't allow people to include arbitrary RDF vocabularies
Steven: the triple relation would be between a string and a URI, right? so it would have to be done with META and not LINK
<Steven> <meta about="http://ns" property="prefix" content="my"/>
Mark: I agree with Steven
Ben: I'm concerned about using a triple for this because the declaration should only be local to the document
Mark: the point is that we can't simply refer to the SPARQL spec because they don't define their term
Ben: but we can use their wording to avoid arguments from opponents of CURIEs
Mark: the SPARQL spec effectively defines CURIEs
Steven: so we could just say that we're using p-names from SPARQL
Mark: but SPARQL has only created its p-name
for use within its own context
... CURIE is meant to resolve this all over
<ShaneM> While there is risk in depending upon another spec, the XHTML 2 working group can complete the CURIE spec now.
Ben: but we've gotten push-back on CURIEs,
including from the Director
... since SPARQL is nearly complete, it would be hard for people to fight us
if we do the same as SPARQL
Mark: looking at the SPARQL spec, we're a lot closer to agreement on CURIE that we were at the time of the Edinburgh AC meeting
Ben: why should we take on this fight?
Mark: we can't refer normatively to [what SPARQL] does just as we can't currently refer normatively to a CURIE spec
Ben: we'll have a bigger fight on our hands if we cite CURIE
Mark: I suggest we take the text and BNF from
the CURIE document and drop it in
... don't use the name CURIE
[adjourned]