- From: David R. Karger <karger@theory.lcs.mit.edu>
- Date: Thu, 4 Dec 2003 16:20:59 -0500
- To: matsakis@mit.edu
- Cc: stefano@apache.org, www-rdf-dspace@w3.org
X-Original-To: www-rdf-dspace@frink.w3.org Date: Tue, 2 Dec 2003 10:42:19 -0500 (EST) From: Nick Matsakis <matsakis@mit.edu> X-X-Sender: matsakis@artoo.ai.mit.edu Cc: SIMILE public list <www-rdf-dspace@w3.org> X-Archived-At: http://www.w3.org/mid/Pine.OSX.4.56.0312011324190.5893@artoo.ai.mit.edu X-Mailing-List: <www-rdf-dspace@w3.org> archive/latest/838 X-Loop: www-rdf-dspace@w3.org X-LocalTest: Local Origin X-Status: X-Keywords: X-UID: 33 On Mon, 1 Dec 2003, Stefano Mazzocchi wrote: >> I think things that don't meet those requirements should get ungetable >> URIs. > What kind of URIs wouldn't meet those requirements, IMO? [not caustic, > just curious] I think its generally pretty clear whether things can be expressed as bits or not. JPEG image? bits. Oil painting on canvas? not bits. There are some digital artifacts whose bits are constantly changing or even never the same, such as websites, but those are still bits (in fact, HTTP can provide metadata for those bits that lets you know whether they are static or dynamic). I don't have any objection to things that can be expressed as bits being given gettable URIs, even if they are not available at those URIs. I'd go the other way around. Whether or not the object being referred to is bits, we should give it a URL if and only if we expect to respond with something "useful" when queried about that URL. Exactly what we respond with doesn't matter so much. Indeed, I could imagine that ultimately HTTPs "content negotiation" evolves into a more general protocol for negotiating what information can be pulled from a URL. The other fringe case is internal nodes in RDF data structures. I'm not sure what the current consensus on this is, but on systems that implement b-nodes they can be blank, and not have any URI. If, for some reason, they do need URIs assigned, then I think ungettable ones would be appropriate. Yes.
Received on Thursday, 4 December 2003 16:21:01 UTC