Re: RDFizing Web 2.0 URIs

Hi Martynas,

It may or may not be the solution you're looking for, but you can
always coin a new URI altogether, e.g.

     http://twitlogic.fortytwo.net/post/twitter/236198363417178112

or in your browser:

    http://semanticreports.com/?uri=http%3A%2F%2Ftwitlogic.fortytwo.net%2Fpost%2Ftwitter%2F236198363417178112

Putting it in your own URI space has the advantage of allowing you to
provide any additional metadata you may have about the resource, when
a linked data client dereferences the URI.  In the case of Twitter,
identifying microposts with Web document URIs may be a little
misleading anyway, as you can get a tweet through multiple APIs.  For
example, the tweet above was received through the streaming API and
not fetched via HTTP.  It might have been helpful if I had also
included links to the HTML pages for tweets, but is the tweet really
the same as the page?

Best,

Josh



On Thu, Aug 16, 2012 at 5:20 PM, Martynas Jusevičius
<martynas@graphity.org> wrote:
> Hey all,
>
> thanks for the links, but I wasn't asking about Twitter specifically
> -- I think it's a more general issue concerning many of the Web 2.0
> APIs.
> The conversion itself is not a problem, but I wanted to find out how
> best to model the relationship between the HTML and API resources.
> They might contain the same or similar content, so to which extent
> they can be treated as equivalent resources? Or is one of them the
> "origin" and the other one the "copy"?
>
> I think many of these questions would simply go away if APIs would be
> built using content negotiation and the same URIs as on the frontend.
> This is what REST is about, isn't it? I don't think it would be fair
> to call Twitter API RESTful.
>
> On the same note, I think JSON really sucks as an API format since it
> cuts off all the XML tools, including XSLT and GRDDL.
>
> Speaking of Twitter, I've got the conversion covered using GRDDL:
> https://github.com/Graphity/graphity-ldp/blob/master/src/main/resources/org/graphity/util/locator/grddl/twitter-grddl.xsl
>
> You can see Twitter resources rendered in Graphity Linked Data browser:
> http://semanticreports.com/?uri=https%3A%2F%2Fapi.twitter.com%2F1%2Fstatuses%2Fuser_timeline.xml%3Finclude_entities%3Dtrue%26include_rts%3Dtrue%26screen_name%3Dgraphityhq
>
> Martynas
> graphity.org
> https://twitter.com/pumba_lt
>
> On Thu, Aug 16, 2012 at 8:36 PM, Hugh Glaser <hg@ecs.soton.ac.uk> wrote:
>> By the way, although http://semantictweet.com/ no longer functions, Mark Borkum's
>> http://shreddedtweet.org/ is alive and kicking and seems to have some documentation of its structures at
>> http://shreddedtweet.org/about
>> Eg
>> http://shreddedtweet.org/search?q=%40timberners_lee
>> Best
>>
>> On 16 Aug 2012, at 10:41, Martynas Jusevičius <martynas@graphity.org>
>>  wrote:
>>
>>> Hey all,
>>>
>>> I'm RDFizing Twitter, and the problem is that its API is not based on
>>> content negotiation and uses a different set of URIs than those
>>> serving HTML to end-users (this issue is not Twitter-specific though).
>>>
>>> For example, these URIs return roughly the same data:
>>> HTML: https://twitter.com/graphityhq/status/235335486707732480
>>> XML: http://api.twitter.com/1/statuses/show/235335486707732480.xml
>>>
>>> Which URI should be used in RDF? If I'm using SIOC, should it be
>>>
>>>  <https://twitter.com/graphityhq/status/235335486707732480>
>>> sioc:content "Graphity #LinkedData..." ;
>>>
>>> or
>>>
>>>  <http://api.twitter.com/1/statuses/show/235335486707732480.xml>
>>> sioc:content "Graphity #LinkedData..." ;
>>>
>>> ?
>>>
>>> SIOC also has a special sioc:link property, and then there is
>>> owl:sameAs and dct:isFormatOf, so I could relate the 2 URIs:
>>>
>>>  <http://api.twitter.com/1/statuses/show/235335486707732480.xml>
>>> sioc:link <https://twitter.com/graphityhq/status/235335486707732480>
>>>  <http://api.twitter.com/1/statuses/show/235335486707732480.xml>
>>> owl:sameAs <https://twitter.com/graphityhq/status/235335486707732480>
>>>  <http://api.twitter.com/1/statuses/show/235335486707732480.xml>
>>> dct:isFormatOf <https://twitter.com/graphityhq/status/235335486707732480>
>>>
>>> Would all of these statements be correct?
>>>
>>> Any best practices for modeling in this situation? Advice appreciated.
>>>
>>> Martynas
>>> graphity.org
>>>
>>
>

Received on Thursday, 16 August 2012 22:54:20 UTC