See also: IRC log, previous 2009-05-28
ACTION: [CONTINUES] Ben to author wiki page with charter template for RDFa IG. Manu to provide support where needed. [recorded in http://www.w3.org/2009/05/28-rdfa-minutes.html#action10]
<msporny> http://rdfa.info/wiki/Rdfa-ig-charter
ACTION: [DONE] Manu to go through and categorize issues and requirements that we should address going forward. [recorded in http://www.w3.org/2009/05/28-rdfa-minutes.html#action12]
<msporny> http://rdfa.info/wiki/Rdfa-in-html-issues#RDFa_Task_Force_Discussion_Order
ACTION: [CONTINUES] Ralph make a request for an RDFa issue tracker instance [recorded in http://www.w3.org/2009/05/28-rdfa-minutes.html#action11]
ACTION: [CONTINUES] Ben to put up information on "how to write RDFa" with screencast possibly and instructions on bookmarklet. [recorded in http://www.w3.org/2008/11/06-rdfa-minutes.html#action12]
ACTION: [CONTINUES] Manu to write summary for Semantic Web Use Cases for Ivan. [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action09]
ACTION: [CONTINUES] Mark create base wizard suitable for cloning [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action12]
ACTION: [CONTINUES] Mark to send Ben ubiquity related wizard stuff [recorded in http://www.w3.org/2008/11/20-rdfa-minutes.html#action11]
ACTION: [CONTINUES] Mark write foaf examples for wiki [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action13]
ACTION: [CONTINUES] Michael to create 'RDFa for uF users' on RDFa Wiki [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action14]
ACTION: [CONTINUES] Ralph or Steven fix the .htaccess for the XHTML namespace [recorded in http://www.w3.org/2009/01/08-rdfa-minutes.html#action01]
ACTION: [CONTINUES] Ralph think about RSS+RDFa [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action15]
<Ralph> issue-214
Ralph: This issue was a comment that came
during the SKOS Candidate Rec period.
... The WG decided that it was more of an editorial question for RDFa TF to
consider.
... There has been a long thread over several years, Ben's aware of the
thread...
Ralph: We should consider providing community
advice in the case where the same URI might be a piece of an RDF vocabulary
or a target in an HTML document.
... In the case where the mimetype of the document is HTML, or
application/rdf+xml
... in the case of RDFa, it's not so clear that an application can
disambiguate between the two types of documents.
... You should not use the same URI for the name in an HTML document as well
as a term in an RDF vocabulary.
... People shouldn't do <p id="foo" about="#foo">
ShaneM: I disagree
... The whole point of RDFa is to embed things in this way.
... I have a URI, which is interpreted in the context of the HTTP request
header.
... A semantic web application will follow-your-nose that should take you to
the definition of a vocabulary item.
... I'm going to prefer xml+rdf
... from a content negotiation perspective, the server should send back what
the requester wants.
... If the request is rdf+xml, then it should extract the triples from the
XHTML document and send those back as rdf+xml.
Ralph: Interesting point.
... The old advice might not matter as much anymore?
... Eric Prudhommeaux might have something to say about this.
Ralph: there might be use cases where the subject of a triple might well want to be a particular bit of HTML markup
Manu: might be something to handle in a validator
Manu: people might do id='foo' and about='foo'
when they're doing vocabulary authoring
... it's nice to be able to drop a vocabulary term into a Web browser and see
a document
Ralph: How can we say something about the ID "foo" <p id="foo" about="#foo"> and not the about="#foo"
Shane: and XML requires something of type ID in
order for the fragment to be valie
... in general, id='foo' about='foo' always occurs when you want to bind
triples to a block in a document
... particularly in definitions of terms
... when referring to a local definition of a term you'd have an ID and you'd
bind to it using @about
... you might also refer to it in @resource
Manu: maybe we should create a Wiki page and develop a best practice in this area
ACTION: Manu create a wiki page for discussion of issue-214 [recorded in http://www.w3.org/2009/06/04-rdfa-minutes.html#action12]
Shane: looking for advice on what are acceptable test suite copyrights
Manu: specifically, is the MIT license sufficient?
ACTION: Ralph find the statement on test suite copyright [recorded in http://www.w3.org/2009/06/04-rdfa-minutes.html#action13]
<rubys> in general, MIT licensed code can be pulled into almost any codebase; the reverse is not necessarily true
<msporny> http://rdfa.info/wiki/rdfa-in-html-issues#RDFa_Task_Force_Discussion_Order
Manu: I'd taken action to propose a discussion order
Sam: suggest moving " Requirement: RDFa
signalling mechanism for XHTML+RDFa, HTML+RDFa, and how does mime-type affect
that mechanism?" higher
... figure out what the signalling mechanism is
... html served as text/xml is interpreted differently by different
browsers
Manu: propose to move the signalling discussion after "target of RDFa processing rules" and before "Do we need to cut features from RDFa to support HTML+RDFa?"
Shane: fine with me
... some of these items have been raised in email but I'm not persuaded
they're really issues
Manu: so move "RDFa signalling mechanism" to 2nd position
Ralph: ok with me
<rubys> if they aren't really issues, they should be able to be disposed of quickly.
<msporny> http://rdfa.info/wiki/rdfa-in-html-issues#The_target_of_RDFa_processing_rules
Manu: question is "on what do the RDFa
processing rules operate?"
... e.g. on a DOM structure [or not]
... now we're trying to explain how this works across all languages
... and generate the same triples across all document [types]
... gets tricky when accounting for serialization issues
... goal is to find a set of rules that works on a parse tree or an abstract
syntax tree rather than on a DOM
... so define the rules in a way not based on serialization of a specific
language
Shane: Mark has a clever way of thinking about
this
... and is very persuasive :)
... as I understand it, Mark's model is that RDFa is at the application layer
so whatever the underlying layer provides to the application is what should
be worked on
... this solves the RDFa specification problem but doesn't solve the "I want
the same triples when I give the same document content to different
things"
... I don't see how we can control the structure of the _input_ to RDFa in a
meaningful way
... will happen differently in legacy browsers, HTML5, new browsers, etc.
... I'm not optimistic that we'll find a way to guarantee the same triples
everywhere
Sam: if we can find a subset that _does_ give
the same triples and note the other cases with a recommendation not to to
those
... can't assume that the consumer respects the well-formed input
requirement
... this requirement is routinely ignored
Shane: ignored by user agents but not by tool chain processors
Sam: wise to accept that some people will be processing this in browsers and give advice on what won't work there
Shane: I do think we can restrict the language so that it has more predictable behaviours under different processing models
Sam: e.g. if a single document has two names that differ only in case, that's probably wierd and don't do it
Shane: yep, we just never considered that case in our prior discussions
Manu: the test cases put on the mailing list
are really good starting points
... we should be clear about what model the RDFa rules are operating on but I
do not see a reason to strip out any rules
... Mark's position is that we can't control the input to the RDFa processing
rules
... we can't control how things get put into a DOM; that's in the domain of
the HTML WG
... so the RDFa processing rules ought to be restated in terms of _some_
incoming model
... RDFa might be used in something that has nothing to do with a DOM
... not a good idea to restrict RDFa to just a DOM
... if you run an HTML document through two different processors, one
producing a DOM and the other not then I don't see how we can guarantee in
all cases to produce the same triples
<rubys> I agree with DOM as the answer to question #1... the problem is that Drupal is producing content with RDFa, and depending on the user agent, it may be processed differently. If you look at Phillip's tests there will be cases where they answers will differ, and some of these can't be solved. In some cases, the answer may be "don't do that". Example: if you define an XML literal and serve the content as text/html, be sure that you don't define any content that HTML5 processing rules will reorder or change in a way that can't be addressed by the parser.
Manu: they _might_ be the same in some cases but I don't think we should try to guarantee the same triples in all cases
Shane: from personal experience, some of our tests produced foreign elements that were removed from the DOM tree I was handed
Shane: I don't have control over this; I can only work on what I'm handed
Manu: can we come up with an example that shows how a well-formed document would generate different triples?
Shane: comes up when embedding foreign stuff,
e.g. SVG -- the SVG simply doesn't show up in the DOM
... there could be RDFa annotations on the SVG but I've lost them
<msporny> Thanks for joining us Sam :)
<msporny> and for your input.
Shane: the XML literal case may well be the
most glaring example
... there are several ways to address this and I don't have a strong
preference for which we pick
... I sort-of like Mark's suggestion to change the default to not be an XML
literal
... so you'd only produce an XML literal in a triple when you explicitly ask
for one
Manu: the side-effect of making it not
automatically an XML literal is that it will process the content
... e.g. <spam about='foo'> inside the content would cause triples to
be generated
Shane: that's probably a corner case
... easier to change behavior sooner than later
Manu: the reason for a change is to make XML
literals the same between HTML and XHTML
... but there's a parallel discussion suggesting that it may be OK for the
triples to differ given different input
Shane: the core issue here is whether it makes any sense to generate XML literals in a non-XML context