W3C home > Mailing lists > Public > public-vocabs@w3.org > June 2014

Re: Benifit of Schema.org over linked data or vice versa

From: Farhana Sarker <fs5g09@ecs.soton.ac.uk>
Date: Tue, 3 Jun 2014 00:28:28 -0400
Cc: W3C Web Schemas Task Force <public-vocabs@w3.org>
Message-ID: <EMEW3|43dc2551b1158df080ed11c1991a46c4q525SU06fs5g09|ecs.soton.ac.uk|7AABBD2F-E1FA-4FBE-AA87-E94401A420DB@ecs.soton.ac.uk>
To: Dan Brickley <danbri@google.com>
Hi Dan,
Thank you very much for your kind explanation of these two terms. Your explanation really helps me a lot.

Best regards,
On 2 Jun 2014, at 09:40, Dan Brickley wrote:

> On 31 May 2014 22:20, Farhana Sarker <fs5g09@ecs.soton.ac.uk> wrote:
>> Hi,
>> I am Farhana Sarker, student in the University of Southampton.
>> I am keen to know the benefit of using schema.org over linked data technology in reusing or interoperability of data or vice versa.
>> Could you please help me in this regards?
> There is no rigid line separating "Linked Data" from other
> RDF-oriented ways of sharing data. Schema.org can be seen as Linked
> Data. But there are differences in emphasis across the community.
> When TimBL originally wrote
> http://www.w3.org/designissues/linkeddata.html it was largely a
> response to the indirect linking model we'd been using in the FOAF
> project. ("This linking system was very successful, forming a  growing
> social network, and dominating, in 2006, the linked data available on
> the web."). Tim was concerned that we (i.e. the FOAF people at the
> time) were missing the opportunity to give re-usable real world
> entities URL Web identifiers; instead FOAF descriptions tended to
> indirectly identify entities, e.g. writing RDF that said "the Person
> whose homepage is http://example.com/person123/", rather than giving a
> formal URI for that Person (see
> http://blog.foaf-project.org/2003/07/identifying-things-in-foaf/
> http://blog.foaf-project.org/2003/07/missing-isnt-broken-data-validation-and-freedom-on-the-semantic-web/
> for the FOAF approaches).  So anyway the Linked Data note advocated
> for all entities to be given HTTP URLs that pointed at RDF
> descriptions. This emphasis ended up becoming a central theme amongst
> Linked Data advocates: the idea that real world entities should have
> HTTP URLs that give you RDF data when you fetch them.
> At that time, RDFa was also fairly new, although the effort was
> underway, http://markbirbeck.com/blog/2004/04/01/xml-europe-2004-rdfxhtml-new-rdf-syntax/
> ... so Linked Data tended to be deployed using distinct
> machine-oriented URLs rather than mixed-in with normal HTML content.
> By the time schema.org was created (2011) it was clear that some of
> the deployment habits considered "best practice" around Linked Data
> were making life hard for publishers, especially those who knew
> nothing about RDF. For example, the expectations that every mention of
> an entity included an HTTP URL pointing at RDF data; that /-based URLs
> redirected, that multiple formats were served using HTTP content
> negotiation; that data used several independently managed RDF schemas,
> etc. etc. ...
> This 2008-style deployment of RDF as Linked Data has been pretty
> successful in various professional settings - e.g cultural heritage,
> archives, libraries
> (http://www.w3.org/2005/Incubator/lld/XGR-lld-vocabdataset-20111025/),
> but was too complex for many mainstream publishers, webmasters and
> developers.
> Schema.org makes different tradeoffs, but in the same design space.
> Schema.org is an RDF vocabulary, even if we don't  shout about the RDF
> side of it to publishers. The central emphasis is on ease of adoption
> by publishers, even if this introduces more noise into the data. So
> for example schema.org has been less emphatic about always
> distinguishing URLs for things from URLs for pages about those things.
> Those are still important distinctions to make, but we are still
> somewhat in the early days of structured data going mainstream - it is
> important to make things easy for publishers and introduce complexity
> gradually.
> The other "break with tradition" at schema.org is the focus on a
> single integrated core vocabulary, rather than an overlapping
> patchwork of independent schemas. Again this is motivated by ease of
> publisher adoption, and by the importance of getting agreement amongst
> high profile consumers. As with entity URLs it is best to consider
> this a matter of emphasis rather than a rigid timeless principle.
> There are lots of places in schema.org where external schemas could
> usefully be combined with the schema.org vocabulary (some discussing
> of this is in http://blog.schema.org/2012/05/schemaorg-markup-for-external-lists.html
> ).
> And as Peter just mentioned, schema.org's vocabulary is defined using
> RDFS a base but with some custom variations. In particular
> schema.org's association of properties with types is very informal,
> almost wiki-like. This is largely due to the fact that schema.org is
> continually growing and evolving while published across millions of
> sites, so we have tried to find ways of keeping things loose, so that
> new type/property patterns can evolve without too much suprise.
> To cut a long story short, schema.org is another effort in the larger
> RDF family. It shares many classic Linked Data concerns but makes
> various tradeoffs favouring broad adoption over data purity.
> hope this helps,
> Dan
Received on Tuesday, 3 June 2014 04:28:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:49:32 UTC