Re: Using Facebook Data Objects to illuminate Linked Data add-on re. structured data

On 6/20/11 4:54 PM, Joe Presbrey wrote:
> On Mon, Jun 20, 2011 at 11:29 AM, Kingsley Idehen
> <kidehen@openlinksw.com>  wrote:
>> Facebook have released structured data in graph form. They've done so in the
>> Information Space dimension and its absolutely a great contribution.
>>
>> owl:shameAs is really about saying: I've made a URI for an object in your
>> data space, and I am exploiting its inherent SDQ at your expense. The
>> "shame" (tongue in check) comes from fact that said entity more than likely
>> hasn't made a Linked Data URI because they are waiting for a concrete
>> business case etc.. In a sense, its about saying: I am eating your lunch and
>> here's how. Thus, use the Name I've minted, and at the very least you'll
>> reduce business model erosion etc..
>>
>> Again: owl:shameAs is old humor (from me) about Linked Data granularity,
>> business models, opportunity costs, and lunch. Don't take owl:shameAs
>> literally :-)
> Thanks for clarifying however eating Facebook's lunch and minting URIs
> that append #this is still not the best recommendation.

For my data space, it works fine. I am saying:

1. I have a local Name for an Entity over in FB's data space -- I make a 
subjective judgment in my data space based on my recognition of the 
structure of their data
2. I don't control the actual Data Format, but I know the Address (a 
Data Source Name or Data Location Name) resolves to structured data (as 
per comment above)
3. #this is my hint to FB saying: you do similar (if you choose) and 
you've added abstraction that disambiguates Name and Address you'll also 
be able to FYN to my data space (via referrer links that you are already 
tracking anyhow) and see my little expansion of data based on that #this 
based Name; ditto others since my Data Space will take to to other 
places etc..

Thus, #this is at worst a good recommendation for those seeking instant 
gratification re. value of Name and Address disamiguation re. HTTP 
scheme URIs and the role they play re. Linked Data :-)

The goal here is to maximize Linked Data prowess exposure with minimum 
disruption to what already exists. That's basically my religion re. new 
technology introduction.

> URIs under a new domain, perhaps (rdf|fql|sparql).facebook.com, should
> be used to clearly distinguish the RDF endpoint from their JSON/graph
> interface.

Don't get you point, bearing in mind, the goal is about a short cut with 
least path of resistance. Why would I want to say that to FB or any 
other entity seeking cost effective materialization of value of the 
"instant gratification" variety?

> I would like to see them add RDFa/microdata, but they have already
> done quite a bit of work against frontend mechanization so I doubt
> that will happen anytime soon.

Who knows?  What I do know is this, instant gratification works wonders 
when trying to coax people into adopting new ideas :-)

For a commercial entity, the rules ae quite simple: shortest path to 
opportunity cost materialization is sacrosanct. These rules apply 
internally when pushing projects to management, and they apply when 
trying to recruit enterprises as partners or customers. Basically, good 
old "show and tell" always works.


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen

Received on Monday, 20 June 2011 16:10:51 UTC