- From: (unknown charset) Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Wed, 22 Sep 2010 10:10:25 +0100
- To: (unknown charset) Noah Mendelsohn <nrm@arcanedomain.com>
- Cc: (unknown charset) Jonathan Rees <jar@creativecommons.org>, (unknown charset) Martin J. Dürst <duerst@it.aoyama.ac.jp>, "Roy T. Fielding" <fielding@gbiv.com>, Norman Walsh <ndw@nwalsh.com>, www-tag@w3.org, MURATA Makoto <eb2m-mrt@asahi-net.or.jp>, Chris Lilley <chris@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Noah Mendelsohn writes: > So, if all that's true, we have a situation where: > > * Code written to normative specification 3023bis would conclude that > the above URI reference resolved to an element (I.e. because the DTD > says that rdf:id is of type ID, which implies that it identifies an > element). > > * Code written to normative reference [media type registration for > application/rdf+xml would conclude that the same URI reference, > applied to the same retrieved representation, resolved to a node in an > RDF graph. > > That seems broken, hence the concern. What am I misundertanding? Why is it broken? We have lots of XML languages which use XML to represent more-or-less abstract data models (W3C XML Schema, for example), in which there is in many cases a one-to-one correspondence between an element in a document instance and an entity in a data model. Given that correspondence, the use of a fragment identifier to pick out the element or the entity in different usage contexts seems perfectly reasonable. (BTW, I think the original sticking point was at a deeper level, based on the understanding that per application/rdf+xml, http://example.org/myrdf.xml#somename identified neither an element, nor a node in an RDF graph, but some resource in the real world.) ht - -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFMmcgCkjnJixAXWBoRAnvFAJ9Aqwge1Qv5IY7PnL1nrzfWqhQe5wCeOm6h PxX+uBmdeJk2bdDjFnMDPPI= =SMGD -----END PGP SIGNATURE-----
Received on Wednesday, 22 September 2010 09:12:21 UTC