- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 18 Jun 2014 18:57:47 -0400
- To: public-vocabs@w3.org
- Message-ID: <53A2196B.3060409@openlinksw.com>
On 6/18/14 4:57 PM, Aaron Bradley wrote: > > Even then, why does TURTLE inclusion pose problems... > > It doesn't. As I said, I'm not opposed to an optional TURTLE tab. Ah! So we agree then :-) > > >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. > > Regarding schema.org <http://schema.org> "Web Developers" and "Web > Masters" have ultimately been the ones responsible for publishing > structured data at scale. Relative scale. Anyone should be able to share an observation via the Web. It's as simple as: ## Turtle Start ## <#this> a foaf:Document ; foaf:topic <#Turtle> ; rdfs:comment """Various RDF Notations for creating Webby Structured Data""" . <#Turtle> rdfs:label "Turtle Notation" ; skos:altLabel "TURTLE" ; owl:sameAs <http://kingsley.idehen.net/DAV/home/kidehen/Public/Linked%20Data%20Documents/GlossaryOfTerms.ttl#Turtle> . ## Turtle End ## > The initiative's focus on employing HTML markup has > succeeded magnificently. Yes, it has, but that is only part of this much longer story, we are only getting started in regards to encoding and decoding information that's transmitted via the Web. Hence the need for us to widen rather than narrow the bandwidth of this endeavor. The goal should be for anyone to be able to say anything, about anything, whenever -- with the maximum amount of ease. We need to get closer to what natural language delivers in the real-world in regards to encoding and decoding of information. Kingsley > > > > On Wed, Jun 18, 2014 at 1:37 PM, Kingsley Idehen > <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote: > > 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 <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 22:58:10 UTC