Re: BNode problem in XHTML2

Hi Steven,

* Steven Pemberton <steven.pemberton@cwi.nl> [2005-05-17 15:32+0200]
> 
> Still trying to get some movement, here is a list of some suggestions for  
> solutions:
> 
> 	1) Two new attributes to represent subject and object when they are  
> bnodes, such as
> 
> 	 	<link some="a" rel="foaf:mbox" href="xxx" />
> 		<link some="b" rel="foaf:mbox" href="yyy" />
> 	 	<link some="a" rel="foaf:knows" other="b" />
> 
> 	Disadvantage: relatively large amount of infrastructure for a rare 
> 	case.o  do.
> 	Advantage: quick t

This seems OK. I don't think bNodes in RDF are at all rare, fwiw.

The specific attribute names ('some' and 'other') seem workable, but 
it might be worth pondering their usability, and considering
alternatives.
 
> 	2) A new URL scheme.
> 	 	<link about="unknown:a" rel="foaf:mbox" href="xxx" />
> 		<link about="unknown:b" rel="foaf:mbox" href="yyy" />
> 	 	<link about="unknown:a" rel="foaf:knows" href="unknown:b" />
> 
> 	Advantage: works now (ie trying to dereference would give you an 
> 	error);
> 		uses existing attributes.
> 	Disadvantage: slow IETF process to register

RDFCore considered this design, and rejected it. 

http://www.w3.org/2000/03/rdf-tracking/#rdfms-identity-anon-resources

http://www.w3.org/TR/rdf-mt/#unlabel
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-URI-Vocabulary
[[
A convention used by some linear representations of an RDF graph to
allow several statements to reference the same unidentified resource is
to use a blank node identifier, which is a local identifier that can be
distinguished from all URIs and literals. When graphs are merged, their
blank nodes must be kept distinct if meaning is to be preserved; this
may call for re-allocation of blank node identifiers. Note that such
blank node identifiers are not part of the RDF abstract syntax, and the
representation of triples containing blank nodes is entirely dependent
on the particular concrete syntax used.
]]

If a form of URI were to be used internally within the RDF/A notation,
we would have to be *very* clear that those URIs were not to leak
out into the resulting RDF triples. The URI is not a URI for the thing 
that the bNode stands for, after all. This is a notoriously subtle 
distinction that has chewed up 1000s of messages on the RDF lists. I
would be very cautious about unleashing it on the wider HTML community.

So I'd file (2) under  "tempting but unworkable".



> 	3) A new XPointer scheme
> 	 	<link about="#unknown(a)" rel="foaf:mbox" href="xxx" />
> 		<link about="#unknown(b)" rel="foaf:mbox" href="yyy" />
> 	 	<link about="#unknown(a)" rel="foaf:knows" 
> 	 	href="#unknown(b)" />
> 	Advantage: uses existing attibutes; W3C process to register.
> 	Disadvantage: have to write the spec
> 
> 	4) Some trick using undefined id's, maybe
> 	 	<link about="#_a" rel="foaf:mbox" href="xxx" />
> 		<link about="#_b" rel="foaf:mbox" href="yyy" />
> 	 	<link about="#_a" rel="foaf:knows" href="#_b" />
> 	   Advantage: existing attributes; quick
> 	   Disadvantage: fragile
> 
> 	5) Use some illegal form of URLs when representing bnodes:
> 	 	<link about="##a" rel="foaf:mbox" href="xxx" />
> 		<link about="##b" rel="foaf:mbox" href="yyy" />
> 	 	<link about="##a" rel="foaf:knows" href="##b" />
> 	   Advantage: may work now.
> 	   Disadvantage: validation.

(3)
Similar issue to (2) above; it overloads the combination of 'href' and 
'rel': sometimes the 'href' carries a URI that is an identifier for 
the thing related by the relationship specified in the 'rel' attribute.
Other times, the 'href' carries a URI that is an identifier for 
a URI-less mention of something. Hard to explain (let alone 
translate into other languages, etc etc). (3) is a special case of 
(2). I consider it undeployable (though it could work from a 
purely engineering perspective).

(4),(5) ... nasty (but clever :) hacks, unworthy of the otherwise 
"clean slate" approach of XHTML2 (Which reminds me to see where the 
imagemaps/svg discussion got to...).

Looks like (1) in some form is the only option, from where I'm standing.

Thanks for following up on this,

cheers,

Dan
 
> Any more?
> 
> Steven

Received on Tuesday, 17 May 2005 20:08:18 UTC