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

Re: last.fm events RDFizing

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 12 May 2009 09:00:07 -0400
Message-ID: <4A0972D7.3000208@openlinksw.com>
To: Keith Alexander <k.j.w.alexander@gmail.com>
CC: David Canos <davidcanos@gmail.com>, Yves Raimond <yves.raimond@gmail.com>, public-lod@w3.org, dataincubator@googlegroups.com
Keith Alexander wrote:
> Hi Kingsley,

Keith,

Adding dataincubator group to the conversation.

The rest of my comments follow inline below.
>
> How does this work under the hood? uriburner recognises the last.fm 
> domain, and parses the URI to understand how to call the last.fm web 
> service api? Then it passes the result to the stylesheet ? Normally 
> uriburner would parse the microformats erdf and rdfa in the page right 
> ? But if the uriburner sponger has a special knowledge of the domain 
> name, it will use other means to generate the RDF ?
>
> What coverage of last.fm URIs are understood ?
The Sponger (Cartridge Manager & Interface) uses URL patterns, content 
type or combination of to determine what a Cartridge processes. Re. 
Last.FM it's patterns:
(http://.*last.fm/.*) | (http://.*lastfm.*/.*) .
>
> http://linkeddata.uriburner.com/about/html/last.fm/user/winningsperm/events 
> doesn't seem to come up with much, and I was hoping for an equivalent to:
>
> http://lastfm.rdfize.com/?username=winningsperm
>
>
>
>>
>> As per earlier post, all the xslt components of our sponger 
>> cartridges are at:
>> http://demo.openlinksw.com/DAV/VAD/rdf_mappers/xslt/
>>
>> Let's tweak rather that reinvent the wheel, everyone is ultimately 
>> time challenged :-)
>>
>
> Yes, if I had known your uriburner service had a last.fm API xslt, and 
> I had been able to get a list of events that a user planned to attend 
> (is this possible?), I would definitely not have reinvented the wheel 
> ...  However, now that it is up there, so long as Tom Heath is happy 
> to host it at rdfize.com (thanks Tom), I think it is good to keep it. 
> It is not a bad thing to have more than one dataset rdfizing the same 
> domain - especially if they link to each other.
Just need everything to cross link so we have smart pathways in the 
Linked Data graphs.

As I stated in Beijing at WWW2008, we are past the stage of basic Linked 
Data euphoria, the broader community of new Linked Data users are going 
to look for much more starting with coherence.
>
> Some differences I have spotted between uriburner and lastfm.rdfize.com:
>
> Your mapping uses Vevent as the rdf:type for the event resources - 
> could you also type it with mo:Performance, or would that have some 
> strange implications?
>
The way we will solve this is via OWL ontology mapping (via UMBEL or a 
Cartridge specific mapping ontology) i.e., a mo:Performance is a 
subclass of a Vevent, for instance.

> I chose mo:performer where your conversion uses foaf:topic
We'll look into that.  Basically, I am going to have github or something 
similar set up for all the RDFizer stylesheets so that we can do more 
dynamic change management etc..
>
> There is also a machine-tag property for the events in last.fm's xml - 
> I minted http://open.vocab.org/terms/machineTag for it.
> I have a vague feeling this could be interesting, and provide a point 
> of linkage into, eg: flickr. Can anyone tell me how I can link into a 
> linked data coversion of flickr or something, using machine tags ?
We should actually produce a SCOT, SKOS, and MOAT based Tag Cloud on the 
fly via Meta Cartridges i.e., post initial graph construction, we then 
finesse via lookups etc.. to make a higher fidelity graph.

Anyway, I think we have a nice starting point re. Music Data Space for 
getting so RDFizer collaboration going, hopefully, this will provide a 
best practices template (re. collaboration) to others across the LOD 
community :-)

>
>
> Keith
>


-- 


Regards,

Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com
Received on Tuesday, 12 May 2009 13:00:43 UTC

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