Fragment Identifier Clarification

I'd like some clarification about fragment identifiers and RDF.

1) To get around the controversy surrounding them [a] - in particular the
"content negotiation" bug [b,c] - the spec says that all URIRefs are
interpreted as comming from "application/rdf+xml" documents [d].  In effect it
contrains any RDF serialization to have fragment identifier format and
semantics identical to RDF/XML, right?

2) What happens if there exists a resource at the URIRef, and several different
representations have incompatible (with "application/rdf+xml" or each other)
fragment identifier formats or semantics?

3) Can a URIRef have two or more fragment identifiers?  That is, so you have
something like:

<tag:example.com,2005-06-18:0248:#one#two#three>

Is that possible?  Is it legal?  What would it mean?  I ask this because for my
application it could be advantageous to pick a URIRef for a resource:

<tag:example.com,2005-06-18:0248:people#APerson>

Then use that for resources that make sense only in his context:

<tag:example.com,2005-06-18:0248:people#APerson#hisDog>

That way it is easy to generate URIRefs and avoid URI collisions at the same
time.  However, I'm unsure whether that is legal or not.

Thanks in advance for answering my many questions!

--
Jimmy Cerra

[a] http://logicerror.com/fragmentProblems

[b] http://www.w3.org/DesignIssues/Fragment.html#Fragment

[c] http://www.w3.org/TR/webarch/#media-type-fragid

[d] http://www.w3.org/TR/rdf-concepts/#section-fragID

[e] http://www.w3.org/DesignIssues/Axioms.html#unique



		
____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

Received on Saturday, 18 June 2005 07:13:11 UTC