- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 18 Jun 2014 16:37:52 -0400
- To: public-vocabs@w3.org
- Message-ID: <53A1F8A0.7050807@openlinksw.com>
On 6/18/14 12:47 PM, Aaron Bradley wrote: > @Richard Wallis said: > > >From my experience it is easier to get your head around/discuss > examples in Turtle and then referring to the > RDFa/JSON-LD/Microdata see how it would be then be implemented. > > I’ve been thinking about suggesting an optional Turtle tab for a > while - so I am now. > > > @Kingsley Idehen said: > >The entity relationships are MUCH easier to understand via TURTLE > notation. Other notations serve specific user profiles. > > From my experience Turtle is virtually unknown outside of the semantic > web community. I just did a straw poll among the developers currently > in my office - none of them slouches - and exactly none of them had so > much as heard of Turtle. You said (and this is really important), your poll was aimed at developers. In my worldview "developers" are a subset of "everyone" . My assertion is that TURTLE Notation is for everyone i.e., a majority of people can map a TURTLE notation based RDF statement to a natural language sentence [1]. They cannot do that with similar ease via POSH (Plain Old Semantic HTML), HTML+Microdata, HTML+RDFa, HTML+JSON-LD, JSON-LD. Data is the plural of Datum. A Datum is a Sentence. Data is a collection of more than one sentences. > > This is not a commentary about the relative usefulness of Turtle, but > on the intended audience of the site and the profile of its adopters - > all the points made by Dan Scott. An optional Turtle tab? Sure, why > not. Turtle as the centerpiece of the code examples? Only if the aim > of doing so is alienating most webmasters. Schema.org is aimed at a human profile currently tagged as "Web Developer" and "Web Master". The assumption is that Schema.org targets both. Even then, why does TURTLE inclusion pose problems if all it does is: 1. widen the audience 2. make relationships comprehensible to document readers. Note, those of us that advocate TURTLE aren't doing so on the basis of structured data publication, this has much more to do with actually understanding entity relationships. The crux of the matter is that when entity relationships are understood modelling is much more productive. > > And I'd use the same logic in arguing against JSON-LD as the default > view. JSON, of course, is - unlike Turtle - readily understood and > used daily by most developers. But remembering, to Dan Scott's point, > that schema.org <http://schema.org> is "a collection of schemas that > webmasters can use to markup HTML pages in ways recognized by major > search providers," it makes little sense to emphasize the syntax which > is currently only tangentially recognized by one of the major search > providers in a very limited context. The trouble is that we always end up in the wrong place i.e., language notation instead of language semantics. RDF is a Language (a system of signs, syntax, and semantics). TURTLE notation makes the entity relationship semantics visible. The other notations blur this most essential item. At the end of the day, folks (users, developer, and others) just want to be able to scribble and share observations, at Web-scale. They don't really want to be constrained by the limitations of search engines. I don't see how adding options can be burdensome if the goal is broadening the audience. I am yet to encounter an argument against mutual inclusion that's justifiable, over the long haul. Let's not (*inadvertently*) use "Web Developer" and "Web Master" as tools of exclusion that simply resurrect old distracting document format wars of yore. An inability to get round the aforementioned issue has dogged RDF since inception. If you check the checkered history of RDF, you'll notice this played out before with RDF/XML on the flawed misconception that "Web Developers" and "Web Masters" would ultimately consume and publish structured data using XML. It failed woefully, and tarnished RDF in the most painful ways. BTW -- I would hold the very same position if anyone pushed the TURTLE Notation only position. RDF is an abstract language, a single notation should never obscure this reality. Links: [1] http://slidesha.re/QEqLZN -- Natural Language & RDF [2] http://slidesha.re/1hF48QL -- Understanding Data Kingsley > > > > On Wed, Jun 18, 2014 at 9:10 AM, Kingsley Idehen > <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote: > > On 6/18/14 10:51 AM, Wallis,Richard wrote: > > >From my experience it is easier to get your head > around/discuss examples in Turtle and then referring to the > RDFa/JSON-LD/Microdata see how it would be then be implemented. > > I’ve been thinking about suggesting an optional Turtle tab for > a while - so I am now. > > > +1 > > The entity relationships are MUCH easier to understand via TURTLE > notation. Other notations serve specific user profiles. Here's the > user profile breakdown as I see it: > > [1] Turtle -- everyone (i.e, anyone literate person that > understand natural language sentences and the role they play re., > information encoding and decoding) > [2] JSON-LD -- Web Programmer that prefers JSON based structured > data representation > [3] HTML+Mircodata -- Web Master focused on HTML > [4] HTML+RDFa -- No real idea as to the profile here (maybe: > Semantic Web Web master ) > [5] RDF/XML -- aimed at XML programmers (but only confused them > and the rest of the world about RDF). > > It would be nice if Schema.org accommodated both TURTLE and > JSON-LD, alongside Microdata and RDFa. > > Kingsley > > > > ~Richard > > On 18 Jun 2014, at 15:44, Markus Lanthaler > <markus.lanthaler@gmx.net <mailto:markus.lanthaler@gmx.net>> > wrote: > > On 18 Jun 2014 at 15:26, Dan Brickley wrote: > > On 18 June 2014 14:15, Antoine Isaac <aisaac@few.vu.nl > <mailto:aisaac@few.vu.nl>> wrote: > > Does this include *real* licenses URIs like > http://creativecommons.org/licenses/by/4.0/ > ? > > Like in the last example in http://schema.org/WebPage ? :) > > (I realise readers don't know what is in each example > 'tab' until they > look... maybe we could improve that) > > I think the problem is, that it is very hard to "see" what > data is in the default's tab (without markup) blob of > text. It's almost impossible to skim it. I'm not sure > whether schema.org <http://schema.org> wants to go down > that route, but I think even for people that have no idea > about how JSON-LD works (or even what it is), it is much > easier to skim and understand. So perhaps that easiest > tweak would be to show the JSON-LD tab by default!? > > > -- > Markus Lanthaler > @markuslanthaler > > > > > > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > <http://www.openlinksw.com/blog/%7Ekidehen> > Twitter Profile: https://twitter.com/kidehen > Google+ Profile: https://plus.google.com/+KingsleyIdehen/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 18 June 2014 20:38:16 UTC