- From: Joshua Shinavier <josh@fortytwo.net>
- Date: Thu, 16 Aug 2012 18:53:52 -0400
- To: Martynas Jusevičius <martynas@graphity.org>
- Cc: Hugh Glaser <hg@ecs.soton.ac.uk>, Semantic Web <semantic-web@w3.org>
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