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

> Even then, why does TURTLE inclusion pose problems...

It doesn't.  As I said, I'm not opposed to an optional TURTLE tab.

>  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 "Web Developers" and "Web Masters"
have ultimately been the ones responsible for publishing structured data at
scale.  The initiative's focus on employing HTML markup has
succeeded magnificently.



On Wed, Jun 18, 2014 at 1:37 PM, Kingsley Idehen <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 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>
> 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>
>>> wrote:
>>>
>>>  On 18 Jun 2014 at 15:26, Dan Brickley wrote:
>>>>
>>>>> On 18 June 2014 14:15, Antoine Isaac <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 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
>> 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
>
>
>
>