Re: More about Facebook Linked Data

Thank you for your comments, Adam.  I agree on every point.  ISWC, Bonn is a very bad example of the Policy/Governance problem that a 24x7 cycle presents.  This is a hold-over problem from the Industrial Revolution.  Unfortunately Bonn just happens to be at an ideal Latitude where the Agricultural Day (measured in Summer) and the Industrial Day (measured in Winter) overlap. TPAC in Santa Clara is a much better example.  And I'm sure many Silicon Valley Company Policies are quite conservative with regard to gadget security risks.  I normally post to the eGov board.  There is broader topical information there.


High Frequency Trading of Securities has no equivalent in the Policy Making business, and as you said ...
"This is a responsibility that the LOD and Semantic Web communities have to be aware of."  


--Gannon



________________________________
From: adasal <adam.saltiel@gmail.com>ith regards 
To: Gannon Dick <gannon_dick@yahoo.com>
Cc: Juan Sequeda <juanfederico@gmail.com>; "semantic-web@w3.org Web" <semantic-web@w3.org>; "public-lod@w3.org" <public-lod@w3.org>
Sent: Wednesday, October 26, 2011 7:41 AM
Subject: Re: More about Facebook Linked Data


The only question is what part of that 16 hours should be devoted 
to work (production) and leisure (consumption), and what gadgets are 
appropriate for use in which activity.
>

I do not know what this has to do with ISWC either way.
But I do think, in a very complex world, it is helpful to focus on simplifying concepts.
Both LOD and the SemanticWeb are obviously about data and information.
There are some psychological points I could make here, for instance that the thirst for data is a form of greed.
The principal point though is that there is a human consumer at the end of the chain.
A proliferation of data is not an increase in information.
Information, as consumed by a person or a group of people has to be formed into something that is not just data. Information can degenerate into data. And thrusting data on some potential consumers of that data maybe financially lucrative, but actually futile.
The internet abounds with examples of this, much of facebook and g+ fall into this category.
But, no doubt, the same might be said about the information that floods traders desks and the flood of emails endemic in most desk bound jobs.
I think that Gannon is trying to point out the obvious. Either one is consuming or producing, but gadgets, and the internet type infrastructure they depend on, rely on confusing the boundary. They rely on a deception, a sleight of hand. This is where they get their greatest traction.
People like to be deceived (there is more to this form of exploitation than I am highlighting here).
People do not like to think that there may be any penalty to be paid for that deception.
Data is not value (judgement) free because it has to be transformed into information, and that cannot be value free.
This is a responsibility that the LOD and Semantic Web communities have to be aware of.

Adam Saltiel 


On 14 October 2011 17:44, Gannon Dick <gannon_dick@yahoo.com> wrote:

Hi Juan,
>
>
>I posted some data for ISWC 2011 consideration.  It stems from 3 ideas ...
>1. Public Sector Information is most usable when limited to small "sectors".  The code overhead necessary to determine everything in the universe from first principles creates a farm with no harvest, because you are constantly pulling up the crops to see how the roots are doing.  This data is about the ISWC venue only (North Rhine-Westphalia).   The concept is that of a Personal Address Book.
>
>2.  Humans are most usable when you pay attention to what they see in the world around them.  Computers do not know, and could not care less, if the lights are on or off, if it's raining outside, etc..  In a small "sector", the environment is not constant, but it changes least, as compared to variability of the universe at-large.
>3. Adult humans need about 8 hours sleep.  So, a sustainable "day" is one that ends about 16 hours after it began.  Most places, this involves getting up in the dark at some times of the year and sleeping in daylight at others.  The only question is what part of that 16 hours should be devoted to work (production) and leisure (consumption), and what gadgets are appropriate for use in which activity.
>
>
>
>So here is the site:  http://www.rustprivacy.org/2011/phase/iswc2011/index.html
>
>
>and a zip file with the raw data: http://www.rustprivacy.org/2011/phase/iswc2011/ISWC.zip
>
>
>--Gannon
>
>
>
>
>
>
>________________________________
>From: Juan Sequeda <juanfederico@gmail.com>
>To: Jesse Weaver <weavej3@rpi.edu>
>Cc: "semantic-web@w3.org Web" <semantic-web@w3.org>; public-lod@w3.org
>Sent: Tuesday, October 11, 2011 5:24 PM
>Subject: Re: More about Facebook Linked Data
>
>
>
>Really cool Jesse!
>
>
>Now imagine linking this data to the ISWC 2011 metadata for the Linked Data-a-thon :)
>http://iswc2011.semanticweb.org/calls/linked-data-a-thon/
>
>
>Don't forget, deadline is Oct 15.. and anybody can participate!!!
>
>Juan Sequeda
>+1-575-SEQ-UEDA
>www.juansequeda.com
>
>
>
>On Tue, Oct 11, 2011 at 4:35 PM, Jesse Weaver <weavej3@rpi.edu> wrote:
>
>APOLOGIES FOR CROSS-POSTING
>>
>>In this email, I would like to reveal a bit more about the Linked Data provided through Facebook's Graph API.
>>
>>
>>AUTHENTICATION
>>
>>Before I get started, I have been asked about how to get an access token.  Information regarding authentication can be found at https://developers.facebook.com/docs/authentication/ .  If you just want a quick way to obtain a security token, just go to https://developers.facebook.com/docs/reference/api/ and click on one of the example "connections" URLs and it will automatically generate a temporary access token (in the URL) for you (if you're logged in to your Facebook account).
>>
>>
>>MORE THAN JUST USERS
>>
>>The main thing I want to point out is that the Graph API is much more than just basic information about users.  See https://developers.facebook.com/docs/reference/api/ for details.  The Facebook graph includes things like pages, checkins, and links; it also includes "connections" (edges between things in the graph).  Anything you can get from the Graph API can be obtained in Turtle via HTTP content negotiation.  Simply include text/turtle in the Accept header (with a higher q preference than more typical mime types if necessary).  One of the most interesting features of the Graph API is the search mechanism:
>>
>>https://graph.facebook.com/search?until=yesterday&q=semantic+web&access_token=<ACCESS_TOKEN>
>>
>>This will include information about a variety of things such as statuses, links, photos, and videos.  (At this point, I feel like I should point out the obvious, that is, that the information you see is only whatever is accessible given the access token provided.)
>>
>>Another cool feature is the ability to ask for information about any number of IDs, where an ID could even be the URL of something included in the Open Graph.  For example:
>>
>>http://graph.facebook.com/?ids=http://www.cs.rpi.edu/%7Eweavej3/index.xhtml,jesserweaver
>>
>>This includes information about my RPI website (which is in the Open Graph) and myself (jesserweaver).
>>
>>
>>LINKED DATA URIs
>>
>>All of the HTTP(S) URIs in the RDF are dereferenceable.  Most of the URIs are hash-URIs (that is, strip off the fragment and fetch the document, returning 200 OK), but there are some slash-URIs (for example, http://graph.facebook.com/schema/%7E/data ) which 303 redirect.  There are also information resources.  It's quite varied.
>>
>>
>>SCHEMA
>>
>>This leads me to discuss the schema (or ontology, or whatever you want to call it).  Even the URIs representing properties and classes are dereferenceable.  For example, http://graph.facebook.com/schema/link#type is the URI identifying the link class, and http://graph.facebook.com/schema/link will return information (with 200 OK) about the link class.  Information includes relevant properties, possibly specifying whether a relevant property is a owl:DatatypeProperty, owl:ObjectProperty, and/or owl:InverseFunctionalProperty.  There may also be rdfs:domain and/or rdfs:range specified where appropriate.
>>
>>There are also properties that are not associated with a specific class, and these (generally) use the http://graph.facebook.com/schema/%7E/ namespace URI.  Properties using this namespace have very vague semantics.  For example, the property identified by URI http://graph.facebook.com/schema/~/data (which 303 redirects to http://graph.facebook.com/schema?tag=data ) has the following description:
>>
>>"A tag having no semantics beyond the conventional semantics of the JSON key \"data\" as used in the Facebook Graph API."
>>
>>So if never_used_as_a_key is never used as a key in the Graph API JSON, then the property http://graph.facebook.com/schema/%7E/never_used_as_a_key is essentially meaningless.  There are two special cases, however.  One is http://graph.facebook.com/schema/%7E/id which is a owl:InverseFunctionalProperty with rdfs:range xsd:string.  The other exception is any URI beginning with http://graph.facebook.com/schema/~/ followed by an optional underscore and then a non-negative integer.  These properties are an attempt at more practical container membership properties.  As an example, check out
>>
>>http://graph.facebook.com/schema/%7E/_14
>>
>>http://graph.facebook.com/schema/~/_14 is a rdfs:subPropertyOf tag:graph.facebook.com,2011:/has (the invented, generic, container membership property) and has an explicitly defined integer index as the value of the tag:graph.facebook.com,2011:/index property (something missing from the RDF container membership properties).
>>
>>@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
>>@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
>>@prefix owl: <http://www.w3.org/2002/07/owl#> .
>>@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
>>@prefix api: <tag:graph.facebook.com,2011:/> .
>>@prefix og: <http://ogp.me/ns#> .
>>@prefix fb: <http://ogp.me/ns/fb#> .
>>@prefix : <http://graph.facebook.com/schema/~/> .
>>:_14 a rdf:Property ;
>>       rdfs:label "_14" ;
>>       rdfs:comment "A tag having no semantics beyond the conventional semantics of the JSON key \"14\" as used in the Facebook Graph API." ;
>>       rdfs:subPropertyOf api:has ;
>>       api:index 14 .
>>
>>
>>OPEN GRAPH
>>
>>URIs used as properties in the Open Graph (except for those in the http://ogp.me/ns# and http://ogp.me/ns/fb# namespaces; those URIs go elsewhere) also redirect to the Graph API schema feature.  For example, http://ogp.me/ns/book#author is a property, and http://ogp.me/ns/book 302-redirects to http://graph.facebook.com/schema/og/book (302 instead of 303 because they are hash URIs).  For information about Open Graph, see http://ogp.me and https://developers.facebook.com/docs/beta/opengraph/ .  Please understand that the Graph API and the Open Graph are NOT the same thing.
>>
>>
>>STATUS OF FB LINKED DATA
>>
>>These are just some of the features of the Facebook Graph API Linked Data.  I have been told that Facebook Linked Data is considered experimental and that continued support depends on the degree of use by developers.
>>
>>
>>I hope this was helpful, and I am happy to attempt to answer any questions.  Please understand, though, that I am not a Facebook employee; I only recently finished an internship there.
>>
>>
>>Regards,
>>
>>Jesse Weaver
>>Ph.D. Student, Patroon Fellow
>>Tetherless World Constellation
>>Rensselaer Polytechnic Institute
>>http://www.cs.rpi.edu/%7Eweavej3/index.xhtml
>>
>>
>>
>
>
>