W3C home > Mailing lists > Public > public-lod@w3.org > May 2009

Re: Segment RDF on BBC Programmes

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 07 May 2009 07:16:50 -0400
Message-ID: <4A02C322.9080700@openlinksw.com>
To: Aldo Bucchi <aldo.bucchi@gmail.com>
CC: Yves Raimond <yves.raimond@gmail.com>, Tom Heath <tom.heath@talis.com>, giovanni.tummarello@deri.org, Richard Cyganiak <richard@cyganiak.de>, Linking Open Data <public-lod@w3.org>
Aldo Bucchi wrote:
> Hi,
>
> On Thu, May 7, 2009 at 6:42 AM, Yves Raimond <yves.raimond@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
Received on Thursday, 7 May 2009 11:17:34 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:20 UTC