See also: IRC log
Ralph: I've been writing RDF/A pages and I had trouble with bnode references in meta and link
Jeremy: bnodes should be implemented, but not well tested
ACTION: [PENDING] Ben to draft full response to Bjoern's 2004 email [recorded in http://www.w3.org/2006/01/24-swbp-minutes.html#action03]
Ben: nearly done but there's a specific issue about rdf:Bag I'd like to discuss
ACTION: [DONE] contact WG and chairs to notify of mistake and prepare the new version. [recorded in http://www.w3.org/2006/01/24-swbp-minutes.html#action01]
ACTION: [DONE] Mark to send Ben his latest XML version of the Primer [recorded in http://www.w3.org/2006/01/24-swbp-minutes.html#action02]
ACTION: [DONE] All in the TF to look at http://www.w3.org/2005/05/hrel/ to decide whether it's ready for WG review [recorded in http://www.w3.org/2006/01/17-swbp-minutes#action03]
Mark: I did a review a bit more and found some more issues than I'd recalled from previous discussions. It will take a more thorough review and discussion
Ralph: from Mark's comments, hrel is clearly not ready for WG review
ACTION: [CONTINUES] Ben start separate mail threads on remaining discussion topics [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action04]
<benadida> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2006Jan/0061.html
Ben: I've done some threads but a few more to do; see REMINDER: Look at Issues Threads
ACTION: [DONE] Ben to draft a new example of RDF/A as an XHTML document that is its own RSS feed [recorded in http://www.w3.org/2006/01/17-swbp-minutes#action05]
Ben: Ian found a bug, so that's good
ACTION: [CONTINUES] Jeremy followup on <head about=...> edge case [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action03]
ACTION: [CONTINUES] Jeremy followup with Mark on the question of multiple triples from nested meta and add to issues list [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action01]
ACTION: [CONTINUES] Jeremy propose wording on reification [recorded in http://www.w3.org/2005/12/06-swbp-minutes#action02]
Ben: start of thread
Ben: it seemed the point being made was that if you have a URI that resolves to an HTML document then you cannot use that URI with a #fragID to refer to a non-Information resource
Mark: yes, there are two related issues:
... the same URI cannot refer to both a Person and [that person's] home
page
... also if a URI refers to something known to be an HTML document ...
... Alistair? felt this might be an unnecessary restriction
Jeremy: Pat Hayes has wonderful things to say on this topic
Mark: but how do you know it's an HTML resource at the start? The conversation that goes on between the agent and the server [affects the outcome]. This all seems to be a mess in the RDF world
Jeremy: this problem goes deep into the heart
of Web Architecture, which is why it's a hard one
... AWWW and
particularly Tim's thinking is influenced by a view that there is a right
answer
[laughter]
Jeremy: that's a modernist viewpoint, part of a
whole philosophy that "if we do things right we can get to a right answer".
In a post-modern world we go with whatever is right for now and deal with
ambiguity. AWWW claims, I think, that URIs should not be ambiguous; a URI
identifies *a* resource and there's an attempt to identify some URIs as
identifying documents; in particular, URIs without a '#'.
When we make the jump from an abstract resource to a document representation
and blur the fragment id as either a fragment of an HTML document or a
fragment of an XML document and not something else as well. The point of view
Pat was articulating is that language is full of ambiguities like these and
it doesn't matter; we cope with the ambiguity in context. One way forward for
Web Architecture is to accept and embrace this ambiguity rather than fight
against it. I agree with Pat's point of view.
The resolution about 303's deals with #-less URIs but still leaves open what
URIs with # really mean. If you get 200 OK plus an information resource, is
the secondary resource identified by # also necessarily an information
resource? This flies against Tim's practice
Ben: doesn't Tim use a #frag in his FOAF file, where the URI does resolve to a document?
Jeremy: yes. One philosophy says it's ok to be inconsistent -- deal with it, another philosophy says it's a failing to be inconsistent and we should work to correct it. There are some deep philosophical issues involved in [this URI#frag discussion] that go throughout our society
<benadida> Tim's Blog
<benadida> Give yourself a URI [in Tim's Blog]
<Ralph> Tim says http://www.w3.org/People/Berners-Lee/card#i is a URI for Tim Berners-Lee
Steven: a home page or a FOAF file is not the same thing as a Person. People who hold opposing point of view won't be swayed by a content negotiation argument. Each content type says what is meant by the frag id
Ben: but what should a URIref with a # resolve
to if it's not an information resource?
... e.g. for example.com/#me to be a Person, what should example.com/ resolve
to?
<jeremy> http://www.w3.org/People/Berners-Lee/card#i
<jeremy> is tim's URI for himself
<jeremy> and
<jeremy> http://www.w3.org/People/Berners-Lee/card
<jeremy> resolves either to N3 or RDF/XML but not HTML
Mark: Tim's FOAF file is saying there's a pure abstraction and it's RDF. He appears to be saying that the only pure abstraction is RDF
Mark: if an RDF processor knows how to extract triples from a document, why should the processor care what the content type is?
<jeremy> whereas http://norman.walsh.name/knows/who
<jeremy> resolves to html
<jeremy> http://norman.walsh.name/knows/who#norman-walsh is hence either a part of a document
<jeremy> or a non-information secondary resource
<Zakim> RalphS, you wanted to correct #-less URIs
Ralph: Jeremy hit the root problem; there's a deep philosophical difference, and this discussion has been ongoing. (personal hat) it's unfortunate that TAG has been annointed to determine what is correct. It would have been better to acknowledge the debate. The httpRange 14 issue is actually not fully resolved, not sure if the TAG intends to fully write it up. The 303 question is not fully explained, but this re-raised point about frag IDs, they should take up. We could raise this issue with the TAG. There are 2 TFs that care about this, us and VM. VM is trying to publish a doc that gives people Apache recipes for dealing with the 303 issue specifically for namespaces, not for other abstract non-information resources. We care more about that second set of resources that are not RDF classes and properties. How do we proceed?
Jeremy: I think a way forward is to concentrate on the "secondary resources". With the secondary resources (#frag), one can argue that the content negotiation gives you "an appropriate part of" the thing you got back but it is not necessary the same type as the primary resource. What we find in the primary resource if we get RDF back is a description of a secondary resource; e.g. Norm Walsh's FOAF file. The architectural idea that we get back a representation of the resource holds only for "primary" resources -- resources without fragment identifiers; what the #frag identifies is MIME-type specific
Ralph: I think this interpretation of #frag is exactly consistent with the MIME type identifier
Steven: what the #frag identifies is indeed MIME-type specific but do the specifications allow this to be of a different type than the primary resource?
Jeremy: Tim's card.n3 URI is an information resource but the fact that card.n3#i happens to return parts of an information resource yet can refer to a non-information resource so he's relying on the MIME type to say that #i is not an information resource
Ben: if I go to example.com/#me and example.com/ resolves to an HTML document that happens to have an ID 'me', which of these is an identifier for a Person? Whichever way the issue is resolved on #-less URIs, we can express both in RDF/A with equal ease
Mark: so what is a #-less URI that represents a Person? My understanding is that you cannot use an HTML element to represent anything other than an HTML element. If the TAG is saying there is something special about HTML IDs i.e. the implication is that #ID on an HTML document is fair game for something other than an HTML element. This I strongly disagree with; this seems to fly in the face of what RDF is all about. It's not a very good solution. If that is what they're saying then we can't do any of the tricks in RDF/A we'd like to do with fragment identifiers in about=; we'd have to spell out full URIs all the time
Mark: it seems that they've added to everyone's triple stores the statement that a fragment identifier on an HTML resource can *only* refer to a bit of HTML and this is bad
<jeremy> +1 to Mark
<benadida> +1 to Mark
Mark: also, what happens if you move a document around from one server to another? It seems wrong that the location of a document determines what statements you are making. Perhaps the statements about "this" document should really be about an anonymous node so when you move the document around these statements continue to say the same thing
<Zakim> jeremy, you wanted to talk about consensus process on http-range-14 and to mention lastminute.com and to address base issue
Jeremy: the problem of moving documents around obviously impacts RDF/XML. The WebOnt group encouraged the use of xml:base. It is conceivable that even with an unfavorable resolution of the secondary resource question we could have different base URIs for each resource
Mark: <head about=""> on head could go with <body about="#">
Jeremy: the empty fragment does not occur in HTML so it's fair game -- but this would be awful
Ben: for next meeting, please take a look at my RSS serialization mail
ACTION: All prepare to discuss Ben's RSS serialization case for 6 Feb telecon [recorded in http://www.w3.org/2006/01/30-swbp-minutes.html#action11]
Jeremy: to get the WD published we should put in a note that identifies which sections do not have consensus
ACTION: Ben add lack-of-consensus notes to the RDF/A Primer [recorded in http://www.w3.org/2006/01/30-swbp-minutes.html#action12]