RDFa Task Force -- 5 Jul 2007

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]

METAs and LINKs in the body: should we get rid of them?

-> [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

@about

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

Ben: in this example, @rel sets the subject because there's no @href

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

CURIEs vs. QNames: what to do for XHTML1.1+RDFa?

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

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]

RDFa Task Force

5 Jul 2007

Attendees

Contents

Action Summary

METAs and LINKs in the body: should we get rid of them?

@about

CURIEs vs. QNames: what to do for XHTML1.1+RDFa?

Summary of Action Items