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

Re: Schema.org v1.6 release candidate: Roles, various fixes, site navigation improvements

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 18 Jun 2014 16:37:52 -0400
Message-ID: <53A1F8A0.7050807@openlinksw.com>
To: public-vocabs@w3.org
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







Received on Wednesday, 18 June 2014 20:38:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:42 UTC