W3C home > Mailing lists > Public > semantic-web@w3.org > August 2012

Re: RDFizing Web 2.0 URIs

From: Joshua Shinavier <josh@fortytwo.net>
Date: Thu, 16 Aug 2012 18:53:52 -0400
Message-ID: <CAPKNUSvyXDaLw6GkZBFOXz_gscAJUBVaP06G_h5PN6KBpwYp-w@mail.gmail.com>
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.


or in your browser:


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?



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:39 UTC