- From: Bass, Mick <mick.bass@hp.com>
- Date: Mon, 7 Apr 2003 23:09:56 -0700
- To: karger@theory.lcs.mit.edu, ks@micky.hpl.hp.com
- Cc: Mark_Butler@hplb.hpl.hp.com, www-rdf-dspace@w3.org
[smathers] > The URL > remains the same, there just needs to be a way of interpreting additional > constraints on the content within that URL. I think this is analogous > to the identification of a ViewPart to extract a particular view of > an object within Haystack (do I remember a SongPreview10Seconds View > Part, or something similar?). In this case the preview isn't meant > to be an aspect of the part however, but a name, which should be > interpreted by the part to extract the relevant information. [karger] > > Having trouble parsing this. > [smathers] Perhaps I can clarify with an example. Consider a DVD archive that contains the theatrical release of "The Lord of the Rings". The URL for this sample asset for the sake of argument is 'http://simile.org/the-lord-of-the-rings-theatrical-release.dvd'. Now suppose I have created a DVD player that will read metadata describing any movie and use it to modify the way that movie is played back. For example, my DVD player can read metadata describing scenes that depict violence, and remove them during playback of the movie. Obviously the metadata read by the DVD player will have to include data that identifies the parts of the overal movie that represent the selected content. Using a URL to represent the content is insufficient -- we can't create new URL's for every possible subregion of a movie, and even if we did so, such an approach wouldn't help in finding an playing back parts of the movie that do not correspond to that URL. Naming, as is being described in section 3.2.7, has nothing to do with the URL for the asset. The purpose of naming is to create a linkage between the metadata and the movie subregion. Stepping out of our example, the purpose of Naming in this document is to represent other assets in ways that URLs cannot. Such linkages are neccessarily specific to the type of data being indexed so they cannot be generalized to a single technology, but that doesn't mean that we can't create a pattern around them. [karger] While using URLs with semantics is one option, an alternative way to specify a particular subpart of the movie is with a blob of RDF. eg, there is a resource foo (no semantics) and assertions "foo fragment-of the-lord-of-the-rings", "foo start-offset 300", and "foo end-offset 500". Whatever semantics I intend to place in the URL, I can instead, without any loss of expressive power, place in a blob of RDF statements. This leaves me with URLs containing no semantics at all, which has a consistency I like. [bass] Note that the same need (to specify sub-parts of an "asset") arises when the asset is itself a bunch of metadata. This is coming up in the work that Jason Kinner is taking on in the history system. Even when all the data is RDF, I believe that the mechanics can be complicated by serialization of the graphs. Then the serialized graph becomes an "asset", that itself has a URL ["A"]. This asset contains several instances (each of which may be named ["B"]) of one or more schema (which are also named ["C"]). The issue here is not so much whether or not URNs are appropriate for each of the names (I believe they are), but rather: 1. by what mechanism are the names generated and assigned? 2. which of the URNs are URI's, and which are URL's? How can I tell? - Here "A" could be a URL, but if I wish it to be location-independent I may assign a URN and use some mapping service (PURLs, Handles). - "B" is probably a URN, not useful to attempt to resolve it. - "C" could be either a URN or a URL. How do I find the schema? 3. how do I resolve the URNs? i.e. given a name, how do I retrieve the thing that it represents: - "A" is a URL - do an http:get - "B" is a URN, which I must map to some query on the contents of the graph represented by contents of "A". - "C" ... not sure I think this is related to what Mark Butler refers to as the need for a "processing model" for RDF.
Received on Tuesday, 8 April 2003 02:10:10 UTC