Re: Segment RDF on BBC Programmes
Giovanni, all, Wading into this conversation a little late, but feel compelled to comment... I'll be honest, I find these kind of RDFa vs RDF/XML vs A.N. Other Publishing Setup discussions tedious and counter-productive. Different technical approaches will be appropriate in different scenarios (*), so whatever our personal preferences let's not make blanket statements in favour of one approach over another without providing qualifying information for people who may be newer to the field and not have in depth appreciation of the subtleties. One of the great strengths of the Linked Data community has been its pragmatism, and while RDFa may be the pragmatic choice in some situations it won't be in others. Cheers, Tom. * At VoCamp in Ibiza we spent some time modelling availability [1], applied to several examples including shop opening times. From a modelling and querying point of view, expressing every availability period explicitly is most straightforward, even if it results in larger numbers of triples. This is probably the desirable behaviour if you're focusing on publishing the raw data (likely to be in RDF/XML I'd guess due to wider tool support) about, say, availability of rental cars at your car hire company, for consumption by SW apps. The converse example, which Peter (Mika) was keen on (having SearchMonkey in mind), was being able to model/express recurring availability periods with exceptions (e.g. this shop is open every weekday from 9am-6pm except public holidays), which sits much more happily with publishing in RDFa, as this is more akin to how people write opening times for human consumption. The upside is fewer triples in total, but the downside is that this modelling pattern is not currently easily SPARQLable if you want to answer queries such as is the shop open tomorrow afternoon. Ultimately data publishers will need to choose the publishing style that suits their context and rely on some machine processing to join the dots; one approach is not *better* than the other. [1] current draft: http://tomheath.com/tmp/availability.ttl 2009/5/4 Giovanni Tummarello g.tummare...@gmail.com: Bravo Kingsley. Here are my 2 lines of encouragement :-) * publish in RDFa and live happy with no content negotiation, redirect 303 to end up with 3 different URIs (/resource /data /page) for what regular folks stubbornly keep believing being the same thing. * make sure you put a semantic sitemap (takes 2 seconds) so that people can find a sparql endpoint and a dump if they want to do more with your data than just tabulator and or not be forced to recursively fetch a lot of stuff thus taking 10 seconds and 80 http requests to show e.g. the labels of what you've published on dblp ;-) Giovanni On Wed, Apr 29, 2009 at 2:01 PM, Kingsley Idehen kide...@openlinksw.com wrote: Richard Cyganiak wrote: On 29 Apr 2009, at 10:17, Yves Raimond wrote: We're aware of the limitations of mod_rewrite to effectively and correctly implement content-negotiation, please see note at [1] and issue at [2]. Any suggestion on this would be greatly appreciated! I've played a bit with several ways of doing it. mod_negotiation seems to be the most sensible solution. However, I did not find a way to make it run with non-static files (e.g. DESCRIBE on a SPARQL end-point). If not using that, then I think the only proper solution left is to code the content negotiation in the actual web application (that's what URISpace does, and I think that's what Pubby does). I reached exactly the same conclusion. I would recommend against the mod_rewrite hack because it is not a full implementation of content negotiation. mod_negotiation works great for static files, for everything else you should probably code your own solution. (And everyone who codes their own solution gets it wrong the first time ;-) In practice, content negotiation is quite an interoperability nightmare. One more point pro RDFa, I suppose. Richard, Should we not simply start an updataed version of LOD deployment best practices in a designated Wiki Space? We certainly need to add the RDFa perspective which isn't reflected in a lot of current material. Others: Apace is not a natural Linked Data Web Server. It is a Document Web Server. Kingsley Best, Richard Cheers! y -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com Please consider the environment before printing this email. Find out more about Talis at www.talis.com shared innovationTM Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete
Re: Segment RDF on BBC Programmes
Hi, On Thu, May 7, 2009 at 6:42 AM, Yves Raimond yves.raim...@gmail.com wrote: Hello! Wading into this conversation a little late, but feel compelled to comment... I'll be honest, I find these kind of RDFa vs RDF/XML vs A.N. Other Publishing Setup discussions tedious and counter-productive. Different technical approaches will be appropriate in different scenarios (*), so whatever our personal preferences let's not make blanket statements in favour of one approach over another without providing qualifying information for people who may be newer to the field and not have in depth appreciation of the subtleties. One of the great strengths of the Linked Data community has been its pragmatism, and while RDFa may be the pragmatic choice in some situations it won't be in others. I completely agree with Tom here, and find this RDFa vs RDF/XML debate quite tedious. For example, in our programmes pages (e.g. http://www.bbc.co.uk/programmes/b00k6mpd) we don't expose all the available versions (signed, shortened, original, etc.) because it is not directly relevant for human consumption - we just merge different things version-related that are relevant (e.g. on-demand audio/video, etc.) to provide a good user experience. So if we were to use only RDFa, we would loose that valuable bit of information. Some data needs to be prodded and merged to not overload the user with information and just present him with bits relevant to human consumption. However, in the raw RDF views, we can provide all these details, that may be relevant for applications, e.g. getting all broadcasts of a signed version of a particular programme. So different publishing methodologies are appropriate for different needs :-) Cheers, y Agree here. In fact, let me say that my own RDFavoritisms have morphed over time as I have run into situations where one approach is better than the other, for any number of reasons. I am doing things now that I once thought to be heresy. I guess the trick is not to argue about what's better/best but to make every possible choice CONSISTENT with the conceptual framework being built, so that every drop of participation adds up and crystallizes. Truth is none of us can foresee which one approach will have the most data 3 years from now. This thing shifts with the winds ( there are more surprises to come, for sure ). Now, what would be useful is a decision tree or a list of recipes. Let newcomers choose but don't overwhelm them with total freedom either. That's the wonder of Linked Data. The simple recipes... that... work! ;) 80/20 Regards, A -- Aldo Bucchi U N I V R Z Office: +56 2 795 4532 Mobile:+56 9 7623 8653 skype:aldo.bucchi http://www.univrz.com/ http://aldobucchi.com/ PRIVILEGED AND CONFIDENTIAL INFORMATION This message is only for the use of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If you are not the intended recipient, please do not distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail. INFORMACIÓN PRIVILEGIADA Y CONFIDENCIAL Este mensaje está destinado sólo a la persona u organización al cual está dirigido y podría contener información privilegiada y confidencial. Si usted no es el destinatario, por favor no distribuya ni copie esta comunicación, por email o por otra vía. Por el contrario, por favor notifíquenos inmediatamente vía e-mail.
Re: Segment RDF on BBC Programmes
Aldo Bucchi wrote: Hi, On Thu, May 7, 2009 at 6:42 AM, Yves Raimond yves.raim...@gmail.com wrote: Hello! Wading into this conversation a little late, but feel compelled to comment... I'll be honest, I find these kind of RDFa vs RDF/XML vs A.N. Other Publishing Setup discussions tedious and counter-productive. Different technical approaches will be appropriate in different scenarios (*), so whatever our personal preferences let's not make blanket statements in favour of one approach over another without providing qualifying information for people who may be newer to the field and not have in depth appreciation of the subtleties. One of the great strengths of the Linked Data community has been its pragmatism, and while RDFa may be the pragmatic choice in some situations it won't be in others. I completely agree with Tom here, and find this RDFa vs RDF/XML debate quite tedious. For example, in our programmes pages (e.g. http://www.bbc.co.uk/programmes/b00k6mpd) we don't expose all the available versions (signed, shortened, original, etc.) because it is not directly relevant for human consumption - we just merge different things version-related that are relevant (e.g. on-demand audio/video, etc.) to provide a good user experience. So if we were to use only RDFa, we would loose that valuable bit of information. Some data needs to be prodded and merged to not overload the user with information and just present him with bits relevant to human consumption. However, in the raw RDF views, we can provide all these details, that may be relevant for applications, e.g. getting all broadcasts of a signed version of a particular programme. So different publishing methodologies are appropriate for different needs :-) Cheers, y Agree here. In fact, let me say that my own RDFavoritisms have morphed over time as I have run into situations where one approach is better than the other, for any number of reasons. I am doing things now that I once thought to be heresy. I guess the trick is not to argue about what's better/best but to make every possible choice CONSISTENT with the conceptual framework being built, so that every drop of participation adds up and crystallizes. Truth is none of us can foresee which one approach will have the most data 3 years from now. This thing shifts with the winds ( there are more surprises to come, for sure ). Now, what would be useful is a decision tree or a list of recipes. Let newcomers choose but don't overwhelm them with total freedom either. That's the wonder of Linked Data. The simple recipes... that... work! ;) 80/20 Regards, A Aldo et. al, Yes, I agree completely! Speaking for myself, I simply want to add the use of RDFa to the Linked Data conversation. Mutually Exclusive approaches to data identity, access, and representation are inherently contradictory to the essence of Linked Data, so RDFa vs RDF/XML vs N3 etc.. doesn't even compute in my world view. Giovanni: RDFa simply joins the list of mechanisms for publishing linked data, no more no less. Content Negotiation is intrinsic to HTTP which is what drives the Web. As stated in my initial response, we just need to add RDFa's use to the Linked Data publishing conversation :-) -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Re: Segment RDF on BBC Programmes
Giovanni Tummarello wrote: Bravo Kingsley. Here are my 2 lines of encouragement :-) * publish in RDFa and live happy with no content negotiation, redirect 303 to end up with 3 different URIs (/resource /data /page) for what regular folks stubbornly keep believing being the same thing. Giovanni, RDFa will not generally negate the essential separation of Name (via URI.URN-URL) and Address (via URI.URL) since Linked Data oriented triples will still contain de-referencable URIs :-) * make sure you put a semantic sitemap (takes 2 seconds) so that people can find a sparql endpoint and a dump if they want to do more with your data than just tabulator and or not be forced to recursively fetch a lot of stuff thus taking 10 seconds and 80 http requests to show e.g. the labels of what you've published on dblp ;-) Sitemap as part of the autodiscovery best practice collection is certainly fine. Note: URI.URN-URL means URN that looks like a URL, which is basically how the Linked Data meme unobtrusively splits resource Name and Address of Description of Resource via hash and slash based URI schemes. I will publish a blog post about this latter -- part of a series of posts aimed at demistifying Linked Data :-) Kingsley Giovanni On Wed, Apr 29, 2009 at 2:01 PM, Kingsley Idehen kide...@openlinksw.com wrote: Richard Cyganiak wrote: On 29 Apr 2009, at 10:17, Yves Raimond wrote: We're aware of the limitations of mod_rewrite to effectively and correctly implement content-negotiation, please see note at [1] and issue at [2]. Any suggestion on this would be greatly appreciated! I've played a bit with several ways of doing it. mod_negotiation seems to be the most sensible solution. However, I did not find a way to make it run with non-static files (e.g. DESCRIBE on a SPARQL end-point). If not using that, then I think the only proper solution left is to code the content negotiation in the actual web application (that's what URISpace does, and I think that's what Pubby does). I reached exactly the same conclusion. I would recommend against the mod_rewrite hack because it is not a full implementation of content negotiation. mod_negotiation works great for static files, for everything else you should probably code your own solution. (And everyone who codes their own solution gets it wrong the first time ;-) In practice, content negotiation is quite an interoperability nightmare. One more point pro RDFa, I suppose. Richard, Should we not simply start an updataed version of LOD deployment best practices in a designated Wiki Space? We certainly need to add the RDFa perspective which isn't reflected in a lot of current material. Others: Apace is not a natural Linked Data Web Server. It is a Document Web Server. Kingsley Best, Richard Cheers! y -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Re: Segment RDF on BBC Programmes
RDFa will not generally negate the essential separation of Name (via URI.URN-URL) and Address (via URI.URL) since Linked Data oriented triples will still contain de-referencable URIs :-) if you can put the RDF and the human legible HTML version in the same address there is absolutely no reason to have separate resources. If you really want to make it clear that its not an informative resource (its not like up to today we had any evidence of this being practically useful or enabling so far, matter of fact there are evidences of the contrary [1]) then just say that in the RDF thisuri isnot aninformativeresource :-) gone with content negotiation, gone with multiple URI URN URL and distinctions among them. I hope we can agree on the principle of keeping things absolutely as easy as possible, as the only way to win (back..) interest from the actual web development circles and have adoption Giovanni [1] http://google-code-updates.blogspot.com/2008/02/urls-are-people-too.html
Re: Segment RDF on BBC Programmes
Giovanni Tummarello wrote: RDFa will not generally negate the essential separation of Name (via URI.URN-URL) and Address (via URI.URL) since Linked Data oriented triples will still contain de-referencable URIs :-) if you can put the RDF and the human legible HTML version in the same address there is absolutely no reason to have separate resources. If you really want to make it clear that its not an informative resource (its not like up to today we had any evidence of this being practically useful or enabling so far, matter of fact there are evidences of the contrary [1]) then just say that in the RDF thisuri isnot aninformativeresource :-) gone with content negotiation, gone with multiple URI URN URL and distinctions among them. I hope we can agree on the principle of keeping things absolutely as easy as possible, as the only way to win (back..) interest from the actual web development circles and have adoption Giovanni [1] http://google-code-updates.blogspot.com/2008/02/urls-are-people-too.html Giovanni, I am absolutely game for clarity and simplicity. So let's work on a document, or contribute to any that may be in development, re. injecting more RDFa into the Linked Data conversation :-) -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Re: Segment RDF on BBC Programmes
On Wed, Apr 29, 2009 at 8:56 AM, John Goodwin john.good...@ordnancesurvey.co.uk wrote: Hi, We just released a new version of BBC Programmes [1] with some nice RDF for segments of programmes. I thought it would be interesting to post it here, as it makes a nice new arrow in the linked data cloud, from BBC Programmes to BBC Music (and from there to DBpedia). Here are some example RDF documents: Segments corresponding to a track being played, linking to the programmes in which this segment happened: http://www.bbc.co.uk/programmes/p002d79n.rdf http://www.bbc.co.uk/programmes/p002rpkp.rdf The segmentation of a programme: http://www.bbc.co.uk/programmes/b00j8dvj.rdf This should be working for all Radio 2 / 6 music programmes. Further services will be handled soon. Great stuff - congrats :) Also, content negotiation is coming! We finally got the approval, and even if it is hacky mod_rewrite based content negotiation, it should work. (Btw, why are the W3C recipes all mentioning mod_rewrite as a way to do content negotiation? AFAIK it is impossible to do proper conneg with it (handling of q values, etc.)). At risk of appearing daft...what does this mean? $ curl -H Accept: text/html;q=1,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/rdf+xml;q=0,text/rdf+n3;q=0 http://www.bbc.co.uk/music/artists/149e6720-4e4a-41a4-afca-6d29083fc091 :-) y John . This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person. Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice. Thank you for your cooperation. Ordnance Survey Romsey Road Southampton SO16 4GU Tel: 08456 050505 http://www.ordnancesurvey.co.uk
Re: Segment RDF on BBC Programmes
Yves, El 29/04/2009, a las 10:56, Yves Raimond escribió: On Wed, Apr 29, 2009 at 8:56 AM, John Goodwin john.good...@ordnancesurvey.co.uk wrote: Also, content negotiation is coming! We finally got the approval, and even if it is hacky mod_rewrite based content negotiation, it should work. (Btw, why are the W3C recipes all mentioning mod_rewrite as a way to do content negotiation? AFAIK it is impossible to do proper conneg with it (handling of q values, etc.)). At risk of appearing daft...what does this mean? $ curl -H Accept: text/html;q=1,application/xhtml+xml,application/xml;q=0.9,*/ *;q=0.8,application/rdf+xml;q=0,text/rdf+n3;q=0 http://www.bbc.co.uk/music/artists/149e6720-4e4a-41a4- afca-6d29083fc091 :-) We're aware of the limitations of mod_rewrite to effectively and correctly implement content-negotiation, please see note at [1] and issue at [2]. Any suggestion on this would be greatly appreciated! [1] http://www.w3.org/TR/2008/NOTE-swbp-vocab-pub-20080828/#negotiation [2] http://www.w3.org/2006/07/SWD/track/issues/58 -- Diego Berrueta RD Department - CTIC Foundation E-mail: diego.berru...@fundacionctic.org Phone: +34 984 29 12 12 Parque Científico Tecnológico Gijón-Asturias-Spain www.fundacionctic.org
RE: Segment RDF on BBC Programmes
Also, content negotiation is coming! We finally got the approval, and even if it is hacky mod_rewrite based content negotiation, it should work. (Btw, why are the W3C recipes all mentioning mod_rewrite as a way to do content negotiation? AFAIK it is impossible to do proper conneg with it (handling of q values, etc.)). At risk of appearing daft...what does this mean? $ curl -H Accept: text/html;q=1,application/xhtml+xml,application/xml;q=0.9,*/*; q=0.8,application/rdf+xml;q=0,text/rdf+n3;q=0 http://www.bbc.co.uk/music/artists/149e6720-4e4a-41a4-afca-6d2 9083fc091 :-) Thanks - it was the q values that was confusing me...is confusing me :) Maybe I'll JGI :) John . This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person. Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice. Thank you for your cooperation. Ordnance Survey Romsey Road Southampton SO16 4GU Tel: 08456 050505 http://www.ordnancesurvey.co.uk
Re: Segment RDF on BBC Programmes
Hello! $ curl -H Accept: text/html;q=1,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/rdf+xml;q=0,text/rdf+n3;q=0 http://www.bbc.co.uk/music/artists/149e6720-4e4a-41a4-afca-6d29083fc091 :-) We're aware of the limitations of mod_rewrite to effectively and correctly implement content-negotiation, please see note at [1] and issue at [2]. Any suggestion on this would be greatly appreciated! I've played a bit with several ways of doing it. mod_negotiation seems to be the most sensible solution. However, I did not find a way to make it run with non-static files (e.g. DESCRIBE on a SPARQL end-point). If not using that, then I think the only proper solution left is to code the content negotiation in the actual web application (that's what URISpace does, and I think that's what Pubby does). Cheers! y
Re: Segment RDF on BBC Programmes
On 29 Apr 2009, at 10:17, Yves Raimond wrote: We're aware of the limitations of mod_rewrite to effectively and correctly implement content-negotiation, please see note at [1] and issue at [2]. Any suggestion on this would be greatly appreciated! I've played a bit with several ways of doing it. mod_negotiation seems to be the most sensible solution. However, I did not find a way to make it run with non-static files (e.g. DESCRIBE on a SPARQL end-point). If not using that, then I think the only proper solution left is to code the content negotiation in the actual web application (that's what URISpace does, and I think that's what Pubby does). I reached exactly the same conclusion. I would recommend against the mod_rewrite hack because it is not a full implementation of content negotiation. mod_negotiation works great for static files, for everything else you should probably code your own solution. (And everyone who codes their own solution gets it wrong the first time ;-) In practice, content negotiation is quite an interoperability nightmare. One more point pro RDFa, I suppose. Best, Richard Cheers! y
Re: Segment RDF on BBC Programmes
Yves Raimond wrote: Hello! $ curl -H Accept: text/html;q=1,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8,application/rdf+xml;q=0,text/rdf+n3;q=0 http://www.bbc.co.uk/music/artists/149e6720-4e4a-41a4-afca-6d29083fc091 :-) We're aware of the limitations of mod_rewrite to effectively and correctly implement content-negotiation, please see note at [1] and issue at [2]. Any suggestion on this would be greatly appreciated! I've played a bit with several ways of doing it. mod_negotiation seems to be the most sensible solution. However, I did not find a way to make it run with non-static files (e.g. DESCRIBE on a SPARQL end-point). If not using that, then I think the only proper solution left is to code the content negotiation in the actual web application (that's what URISpace does, and I think that's what Pubby does). And that's what Virtuoso does too, as showcased via DBpedia and all our AMIs for a while now :-) Links: 1. http://virtuoso.openlinksw.com/Whitepapers/html/vdld_html/VirtDeployingLinkedDataGuide.html Kingsley Cheers! y -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Re: Segment RDF on BBC Programmes
John Goodwin wrote: Hi, We just released a new version of BBC Programmes [1] with some nice RDF for segments of programmes. I thought it would be interesting to post it here, as it makes a nice new arrow in the linked data cloud, from BBC Programmes to BBC Music (and from there to DBpedia). Here are some example RDF documents: Segments corresponding to a track being played, linking to the programmes in which this segment happened: http://www.bbc.co.uk/programmes/p002d79n.rdf http://www.bbc.co.uk/programmes/p002rpkp.rdf The segmentation of a programme: http://www.bbc.co.uk/programmes/b00j8dvj.rdf This should be working for all Radio 2 / 6 music programmes. Further services will be handled soon. Great stuff - congrats :) Also, content negotiation is coming! We finally got the approval, and even if it is hacky mod_rewrite based content negotiation, it should work. (Btw, why are the W3C recipes all mentioning mod_rewrite as a way to do content negotiation? AFAIK it is impossible to do proper conneg with it (handling of q values, etc.)). At risk of appearing daft...what does this mean? Transparent Content Negotiation based quality of service algorithms [1]. This allows a Web user agent and/or server to express representational preferences when processing HTTP requests. Links: 1. http://www.ietf.org/rfc/rfc2295.txt Kingsley John . This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person. Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice. Thank you for your cooperation. Ordnance Survey Romsey Road Southampton SO16 4GU Tel: 08456 050505 http://www.ordnancesurvey.co.uk -- Regards, Kingsley Idehen Weblog: http://www.openlinksw.com/blog/~kidehen President CEO OpenLink Software Web: http://www.openlinksw.com
Segment RDF on BBC Programmes
Hello! We just released a new version of BBC Programmes [1] with some nice RDF for segments of programmes. I thought it would be interesting to post it here, as it makes a nice new arrow in the linked data cloud, from BBC Programmes to BBC Music (and from there to DBpedia). Here are some example RDF documents: Segments corresponding to a track being played, linking to the programmes in which this segment happened: http://www.bbc.co.uk/programmes/p002d79n.rdf http://www.bbc.co.uk/programmes/p002rpkp.rdf The segmentation of a programme: http://www.bbc.co.uk/programmes/b00j8dvj.rdf This should be working for all Radio 2 / 6 music programmes. Further services will be handled soon. Also, content negotiation is coming! We finally got the approval, and even if it is hacky mod_rewrite based content negotiation, it should work. (Btw, why are the W3C recipes all mentioning mod_rewrite as a way to do content negotiation? AFAIK it is impossible to do proper conneg with it (handling of q values, etc.)). Cheers, y [1] http://www.bbc.co.uk/programmes
Re: Segment RDF on BBC Programmes
Hey Yves, Great stuff :) 2009/4/28 Yves Raimond yves.raim...@gmail.com: Hello! We just released a new version of BBC Programmes [1] with some nice RDF for segments of programmes. I thought it would be interesting to post it here, as it makes a nice new arrow in the linked data cloud, from BBC Programmes to BBC Music (and from there to DBpedia). Here are some example RDF documents: Segments corresponding to a track being played, linking to the programmes in which this segment happened: http://www.bbc.co.uk/programmes/p002d79n.rdf http://www.bbc.co.uk/programmes/p002rpkp.rdf The segmentation of a programme: http://www.bbc.co.uk/programmes/b00j8dvj.rdf This should be working for all Radio 2 / 6 music programmes. Further services will be handled soon. Also, content negotiation is coming! We finally got the approval, and even if it is hacky mod_rewrite based content negotiation, it should work. (Btw, why are the W3C recipes all mentioning mod_rewrite as a way to do content negotiation? AFAIK it is impossible to do proper conneg with it (handling of q values, etc.)). That's correct. If they still mention this approach for doing conneg, then the W3C recipes (assuming you mean the ones for publishing vocabs) are outdated and need rewriting. I was under the impression that this was going to happen, but I guess it hasn't yet. Cheers, Tom.
Re: Segment RDF on BBC Programmes
On Tue, Apr 28, 2009 at 2:08 PM, Yves Raimond yves.raim...@gmail.com wrote: Hello! We just released a new version of BBC Programmes [1] with some nice RDF for segments of programmes. I thought it would be interesting to post it here, as it makes a nice new arrow in the linked data cloud, from BBC Programmes to BBC Music (and from there to DBpedia). Here are some example RDF documents: Segments corresponding to a track being played, linking to the programmes in which this segment happened: http://www.bbc.co.uk/programmes/p002d79n.rdf http://www.bbc.co.uk/programmes/p002rpkp.rdf The segmentation of a programme: http://www.bbc.co.uk/programmes/b00j8dvj.rdf This should be working for all Radio 2 / 6 music programmes. Further services will be handled soon. Sorry, it should have read: for all radio 2 and television programmes (for which we have this information, obviously) :-) y
