I think we absolutely agree in principle, richard, great suggestions and advice...
"Within an organisation such as the BBC, maybe what is most important in the first instance is a common set of principles for managing and publishing IDs rather than a one size fits all system?" -- agreed, and that lingua franca is no doubt going to be (is already starting to be) URI identifiers exchanged (internally in the 1st instance) over HTTP... so, in many cases this is in the form of "system-namespace/GUID" : http://some.internal.system.bbc.co.uk/ba853904-ae25-4ebb-89d6-c44cfbd56thy (which for instance, might mean "the iPlayer genre Drama" to that system...) and then there's going to need to be an "equivalency engine" which helps map between all the different systems across the Beeb which know about and have an ID for, say, "Torchwood series 2 episode 6" or "Jonathan Ross"... there's no one "true" ID or URI for these concepts... how true does that ring for you? and, though I really don't want to start a "what does a URI represent?" or "who's more Restful?" flame war, I'm interested in unpacking what you mean by "the musicbrainz example should be a location where you find out information about ³Blur²"... isn't that what the following URL does? http://musicbrainz.org/artist/ba853904-ae25-4ebb-89d6-c44cfbd71bd2.html i.e. that URI is a location where you find out metadata about Blur, isn't it? BTW, I'm thinking about all this in terms illustrated by the following: http://www.w3.org/DesignIssues/LinkedData.html http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/ http://ivanherman.wordpress.com/2007/10/12/wikipedia-uri-s-as-reliable-identifiers-for-the-semantic-web/ http://fgiasson.com/blog/index.php/2007/05/22/browsing-musicbrainzs-dataset-via-uri-dereferencing/ best-- --cs ************** From: [EMAIL PROTECTED] on behalf of Richard Cartwright Sent: Thu 3/6/2008 10:13 AM To: BBC Backstage Subject: Re: [backstage] What would you love to see coming out of BBC Vision in the near future? Hi Chris It¹s not the size or form of your ID that matters, it is what you do with it that counts ;-) For UUIDs, UMIDs or URLs, you need a common understanding of what happens to them in inevitable change. I think of one use for a URL as a reference to a location where content can be expected to change, such as a news service home page, whereas I consider a UUID is immutable, it refers to one item of content for ever. Create a new version of the content and you have to create a new ID. However, this is a way of thinking and true for most ID schemes ... it all depends on how you choose to manage your identifiers. My excursion into the world of AAF has taught me a lot about comprehensive techniques for structuring and managing IDs for, and relationships between, all kinds of different media material. Most of what AAF is about is structural metadata, how one thing relates to another in a package, along a timeline, encoded with a particular codec etc.. This allows you to trace relationships between content through its various authoring stages back to its original source, a kind of super edit decision list. Structural metadata can be enhanced with descriptive metadata, normally using a schema of your own choosing as there is limited agreement between organisations about what this should be. So to build and expose your EverythingBrainz, perhaps what is needed is an API for exploring structural relationships between items of content, perhaps based on UUIDs, and an API for searching on descriptive metadata (actors, locations, scripts, awards) that may return results including related UUIDs? These APIs could be WSDL or ReSTful in style. For example, I personally think the musicbrainz example should be a location where you find out information about ³Blur² ... http://musixbrainz.org/artist/blur Where an item is currently published is really an item of descriptive metadata. Every generation of the page should have its own ID within a content management system and the published URL refers to the currently published version. The API I propose would allow you to find out the ID of the currently published version and, with appropriate permissions, to explore previous versions of the page via ID relationships. UUID, URL, maiden name, doesn¹t matter as long as the relationships are consistent. In summary, I believe that you could use many different ID schemes and many different descriptive metadata schemas. The important things are: understanding relationships between IDs are how they managed over time; how to map between the ontologies of the various different descriptive schema. Within an organisation such as the BBC, maybe what is most important in the first instance is a common set of principles for managing and publishing IDs rather than a one size fits all system? Cheers, Richard On 4/3/08 23:17, "Chris Sizemore" <[EMAIL PROTECTED]> wrote: > cool stuff richard. > > so how do/should we expose GUIDs to the outside world, in a sorta > "Web" kind of way? cause it's not enough to just generate unique IDs > internally, we also have to "broadcast" their, um, "meaning" to the world at > large... > > in other words, seems like you need the ID, some metadata to describe > the thing ID'd, and a publishing/broadcasting mechanism so that other > people/systems know you have info to communicate. > > a la: > > http://musicbrainz.org/artist/ba853904-ae25-4ebb-89d6-c44cfbd71bd2.htm > l > > sounds like the Web to me... and MusicBrainz, for instance, is an > example of all of the above, no? > > but now, don't we need an EverythingBrainz (as a colleague of mine > recently put it)? > > (BTW, i'm a person that feels that URLs, by definition, are GUIDs) > > > best-- > > --cs -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Smethurst Sent: 07 March 2008 10:41 To: [email protected] Subject: RE: [backstage] What would you love to see coming out of BBC Vision in the near future? > here's an example of some work in that direction by my colleague michael > smethurst: > http://bbc-hackday.dyndns.org:2825/programmes/29xn (currently down, > tho -- michael?) is back now - apologies with rdf here: http://bbc-hackday.dyndns.org:2825/programmes/29xn.rdf - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/[email protected]/
