On 6/20/11 4:54 PM, Joe Presbrey wrote:
On Mon, Jun 20, 2011 at 11:29 AM, Kingsley Idehen
<[email protected]> 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
