Re: Design rationale behind the current schema for Facebook Open Graph Protocol

Hi Fabien,

Thanks for encoding our agreement from the workshop! I agree with all 
the points below.

Two additional comments:

#1

To strengthen commitment,  I would still encourage us to create a custom 
XSLT that maps OGP to the desired representation in RDF/XML. I'm not 
sure RIF or SPARQL Construct is powerful enough to express this mapping, 
and almost everyone has an XSLT parser at hand.

Would you take a crack at it? In a similar fashion, an OGP to JSON 
mapping would be also highly desirable, otherwise implementations will 
diverge on the JSON serialization.

#2

The four generic attributes are required, i.e. something is not an OGP 
document unless it has all four  (per spec, but maybe David can comment).

It seems tricky to model this without a class (what would you put the 
constraint on?), so maybe time to introduce an og:Document class as a 
holder for these properties.

Peter

p.s. Tools are already diverging? It looks like IMDB has OGP data, but 
this tool listed on the OGP page doesn't find it:

http://www.opengraph.in/?url=http%3A%2F%2Fwww.imdb.com%2Ftitle%2Ftt1315981%2F&format=html



Fabien Gandon wrote:
> First of all, thank to all of you who sent us feedback.
>
> The schema is served at http://opengraphprotocol.org/schema/ for clients 
> accepting application/rdf+xml header.
>
> To answer some of the questions, here is a summary of the design 
> rationale behind the current version of the schema.
>
> Let us take the current example on the OPG page:
>
> <html xmlns:og="http://opengraphprotocol.org/schema/">
> <head>
> <title>The Rock (1996)</title>
> <meta property="og:title" content="The Rock" />
> <meta property="og:type" content="movie" />
> <meta property="og:url" content="http://www.imdb.com/title/tt0117500/" />
> <meta property="og:image" 
> content="http://ia.media-imdb.com/images/rock.jpg" />
> ...
> </head>
> ...
> </html>
>
> This code is indeed found in the header of the page 
> http://www.imdb.com/title/tt0117500/
>
> If we want to keep that as simple as it is (no blank nodes, no 
> additional href, no additional namespaces, etc.) the triples generated 
> are datatypeproperties (use of <meta/>) attached directly to the page:
>
> <http://www.imdb.com/title/tt0117500/> og:title "The Rock"
> <http://www.imdb.com/title/tt0117500/> og:type "movie"
> <http://www.imdb.com/title/tt0117500/> og:url 
> "http://www.imdb.com/title/tt0117500/"
> <http://www.imdb.com/title/tt0117500/> og:image 
> "http://ia.media-imdb.com/images/rock.jpg"
>
> A direct mapping of these properties to dc :title, rdfs :type, etc. 
> would imply triples annotating the page itself like which would be not 
> exact and/or invalid:
>
> <http://www.imdb.com/title/tt0117500/> dc:title "The Rock"
> <http://www.imdb.com/title/tt0117500/> rdfs:type "movie"
> <http://www.imdb.com/title/tt0117500/> foaf:homepage 
> "http://www.imdb.com/title/tt0117500/"
> <http://www.imdb.com/title/tt0117500/> foaf:depiction 
> "http://ia.media-imdb.com/images/rock.jpg"
>
> Rather the triples should look like for instance:
>
> _:a dc:title "The Rock"
> _:a rdfs:type <http://opengraphprotocol.org/schema/Movie>
> _:a foaf:homepage <http://www.imdb.com/title/tt0117500/>
> _:a foaf:depiction <http://ia.media-imdb.com/images/rock.jpg>
>
> Therefore, instead of forcing equivalent properties or sub-properties we 
> have chosen a minimal ontological commitment that allows everyone to 
> extend it as needed. To summarize : the idea behind the current version 
> is that most mappings demand some tricky alignment like creating bnodes 
> for Addresses or Objects while the RDFa code must remain very very 
> simple. So we just capture the voc they use with their semantics and 
> then have the mapping and translation done through rules (N3 rules, 
> SPARQL Construct, RIF etc.) or other mechanisms e.g. have a rule to 
> transfrom the ogp "keyword types" into URIs, have a rule to create a 
> resource for the page and another one for the object, etc.
>
> If we were to change the RDFa  markup better mapping could be done.
>
> Feedback is more than welcome.
>
> Cheers,
>
>

Received on Saturday, 1 May 2010 21:37:36 UTC