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.tummarello@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 <kidehen@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 it. Any use of this e-mail by an unauthorised recipient is prohibited.
>
> Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
Dr Tom Heath
Researcher
Platform Division
Talis Information Ltd
T: 0870 400 5000
W: http://www.talis.com/

Received on Thursday, 7 May 2009 09:42:43 UTC