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

On 13 June 2011 10:29, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> On 6/13/11 8:46 AM, Richard Cyganiak wrote:
>>
>> On 12 Jun 2011, at 22:05, Kingsley Idehen wrote:
>>>
>>> Example using the URL: http://graph.facebook.com/kidehen:
>>>
>>> {
>>>   "id": "605980750",
>>>   "name": "Kingsley Uyi Idehen",
>>>   "first_name": "Kingsley",
>>>   "middle_name": "Uyi",
>>>   "last_name": "Idehen",
>>>   "link": "https://www.facebook.com/kidehen",
>>>   "username": "kidehen",
>>>   "gender": "male",
>>>   "locale": "en_US"
>>> }
>>
>> Ok so you got this JSON from here: http://graph.facebook.com/kidehen
>>
>> Then you go on to say that it would be much better if it said:
>>
>>    "id": "https://www.facebook.com/kidehen#this"
>>
>> instead of:
>>
>>    "id": "605980750"
>>
>> But given that you can't get any JSON from
>> https://www.facebook.com/kidehen#this, wouldn't it be better if it said:
>>
>>    "id": "http://graph.facebook.com/kidehen"
>>
>> or even, as Glenn proposed:
>>
>>    "id": "http://graph.facebook.com/605980750"
>>
>> Both of these resolve and produce JSON.
>
> I should have said: http://graph.facebook.com/605980750#this :-)

Chatted with Joe and Nathan about this some time back.

I think there as an argument that said you can get away with not using
the #this ... ill try and dig up the notes if you would like a pointer

>
>>  So if I wanted to refer to you in my app, it seems like these two would
>> be quite handy identifiers, and superior to the one you proposed, no?
>
> Yes, as per above.
>
>
> Kingsley
>>
>> Best,
>> Richard
>>
>>
>>
>>> Some observations:
>>>
>>> "id" attribute has value "605980750", this value means little on its own
>>> outside Facebook's data space.
>>>
>>> Now imagine we tweaked this graph like so:
>>>
>>>
>>> {
>>>   "id": "https://www.facebook.com/kidehen#this"
>>>   "name": "Kingsley Uyi Idehen",
>>>   "first_name": "Kingsley",
>>>   "middle_name": "Uyi",
>>>   "last_name": "Idehen",
>>>   "link": "https://www.facebook.com/kidehen",
>>>   "username": "kidehen",
>>>   "gender": "male",
>>>   "locale": "en_US"
>>> }
>>>
>>> All of a sudden, I've used a HTTP scheme based hyperlink to introduce a
>>> tiny degree of introspection.
>>>
>>> I repeat this exercise for the attributes i.e., Name then using HTTP
>>> scheme URIs, and likewise for values best served by HTTP scheme URIs for
>>> boundlessly extending the object above, courtesy of the InterWeb.
>>>
>>> Even if Facebook doesn't buy into my world view re. data objects, my
>>> worldview remains satisfied since I can ingest the FB data objects and then
>>> endow them with the fidelity I via use of URI based Names.
>>>
>>> Example Linked Data Resource URL:
>>> http://linkeddata.uriburner.com/about/html/http://linkeddata.uriburner.com/about/id/entity/http/graph.facebook.com/kidehen
>>> .
>>>
>>> Example Object Name from My Data Space:
>>> http://linkeddata.uriburner.com/about/id/entity/http/graph.facebook.com/kidehen
>>> .
>>>
>>> A little structured data goes a long way to making what we all seek
>>> happen. Facebook, Google, Microsoft, Yahoo! etc.. have committed to
>>> producing structured data. This commitment is massive and it should be
>>> celebrated since it makes life much easier for everyone that's interested in
>>> Linked Data or the broader Semantic Web vision. They aren't claiming to
>>> deliver anything more than structured data. At this time, their fundamental
>>> goal is to leave Semantic Fidelity matters to those who are interested in
>>> such pursuits, appropriately skilled, and so motivated.
>>>
>>>
>>> --
>>>
>>> Regards,
>>>
>>> Kingsley Idehen
>>> President&   CEO
>>> OpenLink Software
>>> Web: http://www.openlinksw.com
>>> Weblog: http://www.openlinksw.com/blog/~kidehen
>>> Twitter/Identi.ca: kidehen
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
> --
>
> 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 Wednesday, 15 June 2011 13:14:41 UTC