NO to "expertise" as the chosen term. I do not think that is the need at all. @danbri I do not think you are getting a clear picture from them.

The term "expertise" is too closely analogous to "skills" or "skilled".

I understand that News Organizations what to say that an author covers a domain, has an interest in, "cybersecurity" but is not considered "expert" or "skilled" in "cybersecurity". News Organizations WILL use at times outside consultants or experts in a "cybersecurity" field, etc.

I think their need is one of "writesAbout" or "interestedIn", etc.

Let's come up with a better term than "expertise" that covers that need for News Organizations to say that an author writes stories in their interest area, or domain of interest, etc. but is not "skilled" in it.

https://medium.com/@ellekaplan is "skilled" as a Financial Expert and writes about Finances.
http://www.cnn.com/profiles/john-blake is "skilled" in Religion, and has an "interest" in Politics and writes about both.
https://www.linkedin.com/in/daveasiegel is "skilled" in Social Media, and has an "interest" in Comedy.

@thadguidry the intended distinction (which imho is reasonable) is between knowing about something vs being good at doing it. Many scholars also have that characteristic. There is also looming the matter of competency frameworks from the learning/edu metadata scene. This is a stronger claim that "writes about". I might have significant expertise regarding sports or certain sciences without being a practitioner; by contrast I might be interested in or write about things that are really beyond my expertise. Perhaps it depends upon your view of general journalistic practice which pattern best captures news reporting currently.

@danbri Call me picky. Very picky. But I strongly feel that word will confuse folks.
I strongly feel you are not using the right word for what you are trying to explain. https://www.google.com/search?q=definition+of+expertise&oq=definition+of+expertise

expertise -
expert skill or knowledge in a particular field.
the skill of an expert.

Again, I feel strongly that the English word "expertise" is too analogous to "skilled". The idea of expertise includes either "skill" or "knowledge" and not just "knowledge".

UPDATE: If the News Organizations want "expertise" .. then they will have to convince me and demonstrate to me a clear difference from "skill". Because in my world, even having tipped my toe in journalism many times, those 2 terms are highly interchangeable.

well, that is why we are here. I floated a strawman to get some opinions. Let's see if others have suggestions too.

Talking with Sally and @subbuvincent at @TheTrustProject --- for the language aspect, I think their usecase would be handled by a "speaksLanguage" property (taking simple Text or more explicitly coded Language as values). More nuanced things (e.g. native speaker, learner etc) could be handled later via subproperties.

(we have a dedicated issue for this somewhere in github but I didn't find it yet...)

Agree that 'expertise' is not the best description. With a Specialty (especially subtype MedicalSpecialty, you are either formally "certified in" , or self-acknowledged "skilled in".

Agreed that 'expertise' is the wrong name for the term - but there is a difference between "practices" and "knowsAbout" (which is my strawman replacement for "expertise"

With regards to langauge, I think you want something like knowsLanguage - speaking, listening, reading and writing are actually very different for a large number of languages and while the first use-case might just want a single property, I expect we will quickly find that there is a need for explicit subproperties to represent each of these capabilities.

For example many people can speak chinese or japanese far better than they can read or write them, and many people can read European languages at a high level, but cannot speak or even understand them spoken.

(My own case is portuguese - it never occurs me to look for a translation of written portuguese since I have no problem reading it, and in general I am happy to give a talk in portuguese because people understand it. But if someone speaks portuguese to me I am unlikely to understand much, and I cannot write more than very basic sentences).

Extending from what @chaals is saying, @danbri: knowsLanguage seems like a good idea for a general property that could have speaksLanguage, readsLanguage and writesLanguage as sub-properties.

knowsLanguage:
|- speaksLanguage: - lang codes
|- readsLanguage: - lang codes
|- writesLanguage: - lang codes

From a type Person's knowsLanguage's perspective, this will allow different end-user orgs and people to be able to use these properties.

For deeper characterization involving language credentials of some kind, native speaker, learner, etc., this might not fit.

You missed one :)

signsLanguage: - lang codes

"Although sign languages have emerged naturally in deaf communities alongside or among spoken languages, they are unrelated to spoken languages and have different grammatical structures at their core." https://en.wikipedia.org/wiki/Sign_language

ISO 639 Part 3 has them like "Afghan Sign Language" - afg
http://www-01.sil.org/iso639-3/codes.asp

With "expertise" we aim to identify what a journalist has knowledge about - either through experience in covering that topic or through training, whether academic or some other type. @chaals is going in the right direction but knowsAbout doesn't convey any basic threshold of knowledge.

knowsAbout doesn't convey any basic threshold of knowledge

That's sort of true, but I don't think we have nya mechanism for effectively demanding some particular threshold when people assert that they are "experts" - and short of trying to attach a bunch of CV information or using a framework for verifiable claims, I doubt there is any likelihood we can make something work sufficiently well to be reliable.

So we're left almost at expressing an "interest in" a topic or thing, but that feels as wrong as "expertise". I'm interested in programming theory and automated algorithm optimisation, I knowAbout chinese language and official non-judicial dispute resolution procedures in australia, and I have skill/expertise in Spanish and accessibility...

Would "knowledgeArea" or "knowledgeDomain" be a better compromise between "expertise" and "knowsAbout"?

@vholland asked

Would "knowledgeArea" or "knowledgeDomain" be a better compromise between "expertise" and "knowsAbout"?

For my money, I prefer the plain speaking style of "knowsAbout", and it seems clear (to me) in which direction the property goes. But this is getting into then aesthetics of design to a level at which I am not going to argue very hard - those proposals also sound good enough to me, and particularly if there is a sense that more formal language actually makes users happier, then why not...

@chaals I have to admit to not caring terribly and being fine with "knowsAbout". I just want to avoid endlessly debating something relatively minor in the grand scheme of things. Lord knows I have added far worse terms than anything suggested here.

Couldn't care less either. Except for one little thing... We have http://schema.org/about already. Having a "knowsAbout" does make things a bit easier for relationship handling outside of Schema.org context.

@thadguidry If you can live with "knowledgeArea" or "knowledgeDomain", either of those terms would work better for us.

I also like the plain speaking approach of "knowsAbout", although it feels a touch more colloquial than our usual tone. It fits with the (also slightly awkwardly named) "about" property, and could take the same values and could equally benefit from controlled value lists if these emerge later.

In favour of plain speaking: the original World Wide Web project had an informal slogan, "Let's share what we know". They could have written "Let's share our knowledge domains", but I'm glad they didn't.

On the question of entry-level competency thresholds, it is tricky. My advice would be to step up from making a single property do an impossible amount of work, and take the view that a whole range of existing properties (e.g. worksFor, alumni) can provide competence evidence, and that further work in that direction is also likely but with collaboration from people working around schemas for educational materials, courses and jobs. I don't want to pre-empt that work by rushing something solely for the news case. Note also that we already have http://schema.org/Permit which is somewhat relevant (consider someone having a driving license, truck or taxi driving permit, vs. educational qualifications).

Proposal:

1.) knowsAbout (of a Person or Organization), "Represents the domains of interest and expertise of a person or organization."

2.) knowsLanguage (of a Person), "A language that this person has some competence with (e.g. speaking, reading, writing, signing, ...)" ( + explain how to use the lang codes)

Can we also define what value formats 'knowsAbout' could take?

We could use text strings like ["Urban development", "Stock markets",..] i.e., an array of strings. Did you folks have something else in mind?

@subbuvincent I would say Text (always implied in Schema.org) and URL. I'd say NO to http://schema.org/identifier and PropertyValue.

@danbri we already went colloquial :) http://schema.org/knows and http://schema.org/follows
And yes, that's what I was alluding to, that knowsAbout makes it an easier fit around the universe of Linked Data.

I'm happy with "knowsAbout" with @danbri 's definition.

+1 to knowsAbout and knowsLanguage.

Did we include for whether the knowsAbout construct will cover for indicating local expertise as well? This is last bullet in @danbri's original post on this thread.

for example some author might be a "Person" with "expertise" which is a "Specialty" which has >> an association with a "Place" e.g. Tampa Florida

The Trust Protocol has defined the local expertise an author could have sub-attribute in two parts itself. Local and Demographic expertise.

Shall we just say that since knowsAbout is taking text values, we will account for this there? I.e. place names, demographic descriptions? Here is a composite example

"author": {
"@type": "Person",
"name" : "Jane Doe",
"knowsAbout": ["Environment", "Energy", "Charleston, West Virginia, USA", "Women"],
..
}

The first two terms are topics, the third is a place (where the text setup is also lat-long convert-able), and the fourth is a demographic.
..

It seems natural that local expertise would be included, since there is nothing exceptional about it as a branch of knowledge.

One thing to consider is whether we might want to allow actual structured entity descriptions (or URLs that correspond...) as values of knowsAbout. For example,

"@context": "http://schema.org/",
"@type": "Article",
"author": {
 "@type": "Person",
 "name" : "Jane Doe",
 "knowsAbout": ["Environment", "Energy", { "@type": "Place", "name": "Charleston, West Virginia, USA"}, "Women"]
 }
}

It's worth considering. We have a CMS-UX conversation happening right now with a major newsroom group. In principle if they allow location expertise to captured as a separate data field like [place name] say like this

field1 [ ....] Topic and demographic items
field2 [....] Locations (place names)

..then yes, they would consider adding backend code to the system to spit out markup exactly the way you say. It's a little more dev work.

Btw, @danbri I did not know a @type can invoked this way with something that took text values!

@subbuvincent well we're still designing the property here, so my example was exploring the idea that knowsAbout expects take text values, URLs and also maybe at least Place. A simpler example with only a single value shown would be as below.

In this example I've added a sameAs to disambiguate the Place. Note that this is much more in the tradition of Web 2.0 tagging, i.e. the values of the property are 'AND'-d together but taken as independent. If you want to say that the thing known about is Environment/Energy issues in Charlestone, as well as (but unrelated to) women/gender, you'd need a more powerful representational system. Something like library subject classification codes (UDC, Dewey) could work there but come with their own complexities. Allowing URLs is a reasonable step in that direction e.g. http://ddc.typepad.com/025431/2012/06/ddc-23-released-as-linked-data-at-deweyinfo.html http://www.udcdata.info/ http://id.loc.gov/authorities/subjects.html etc. /cc @vholland

If the type of a Place is included explicitly as here, it would reduce the desire to break out places into their own property, knowsAboutPlace. People might reasonably ask why only places get the special treatment, e.g. recipes, events, people etc can also be known about. Generally we try to avoid having too many properties defined only with "Thing" but we might be heading that way here.

"@context": "http://schema.org/",
"@type": "Article",
"author": {
 "@type": "Person",
 "name" : "Jane Doe",
 "knowsAbout": { 
     "@type": "Place", 
      "sameAs": "https://www.wikidata.org/wiki/Q44564",
      "name": "Charleston, West Virginia, USA"
    }
  }
}

@danbri On this:

1 The AND-ding.

If you want to say that the thing known about is Environment/Energy issues in Charlestone, as well >>as (but unrelated to) women/gender, you'd need a more powerful representational system.

In the current phase of the Trust Project, the expertise attribute values between Location and Topics are not expected to be AND-ed. They are literally, 'stateless' or 'memoryless' of each other right now. @TheTrustProject (Sally) will have a better sense for whether she wants the Author Info working group to consider this for a later protocol development.

2 Wikidiata sameAs disambiguation. For Newsroom CMSes to mark this up they will either need to do a Wikidata query during setup for that author, or cache a table locally, use it for lookup and spit sameAs out on the page. So it has dev implications.

@type Place also has Place->geo and if there is a lat-long system in the CMS, they could signal the out for disambiguation too. That has dev implications for legacy CMSes too. (Though I like your sameAs proposal, actually). Could we leave the locational disambiguation out as optional for now? (It primarily comes up in cases where two or more places with the same name exist in the same state in the country. Which can happen as in Springfield, PA, USA I think.)

Here is a slightly revised versions of your snippet, to add topics and demographic text values and make it composite.

"@context": "http://schema.org/",
"@type": "Article",
"author": {
 "@type": "Person",
 "name" : "Jane Doe",
 "knowsAbout": ["National Security", "Military", "Women", "Transgender issues", { 
     "@type": "Place", 
      "name": "Charleston, West Virginia, USA"
    }]
  }
}

@danbri The PoW article will carry expertise attributes too, so your general example, iterated by me in above comment is good enough for our discussion.

Adapting the markup for the author page to continue the example:

"@context": "http://schema.org/",
 "@type": "Person",
 "name" : "Jane Doe",
 "knowsAbout": ["National Security", "Military", "Women", "Transgender issues", { 
     "@type": "Place", 
      "name": "Charleston, West Virginia, USA"
    }]
  }
}

Ok, added drafts of knowsAbout and knowsLanguage. They're committed to master branch here and should show up on webschemas.org for discussion shortly.

Hi Everyone:

Sally (@TheTrustProject) and I were talking about the definitions and this got us onto a potential concern about the meaning of the term 'Corrected Work'. For journalism use cases, corrected-work will typically mean the article-that-got-corrected by the original publisher. I.e. the article that had the error is now updated with the correction.

We felt the tech-review and MIT example is more suited to something we could call 'externally corrected work' or 'external response/comment/clarification'-work that the original site could markup, in addition to their own correction.

We also wondered if mainEntityofPage -- which I used to markup the corrected-work in my previous example, might be an overload for meaning, going by how it's defined in the background page.

So I wanted to propose an alternative markup going over the cases again.

1 Real example from a New York Times correction on an Oscars 2018 piece. The Trust Project considers this a regular journalism use case (the original article carries the correction in the UX, and there is no external correction offered/referenced)

<script type="application/ld+json">
{"@context":"http:\/\/schema.org",
	"@type":"ReportageNewsArticle",
	"url":"https://www.nytimes.com/2018/01/23/movies/oscars-snubs-surprises.html",
	"publisher": ...
	"datePublished": ..
	"dateModified": ..
	"headline":"...
	"mainEntityOfPage":"https://www.nytimes.com/2018/01/23/movies/oscars-snubs-surprises.html",
"correctionComment": [ 
		       {"@type":"Comment",
			"text": "An earlier version of this article misstated the number of times Denzel Washington has been nominated for an Oscar. His nod for “Roman J. Israel, Esq.” brings the total to nine, not eight.",
 			"datePublished" : "2018-01-23”,
	                “correctedWork”:”https://www.nytimes.com/2018/01/23/movies/oscars-snubs-surprises.html"
         		}
		    ]

2 Real example from the MIT Tech Review, which a different MIT body - the MIT Media Lab posted a response to. In the news industry, this would be considered an 'external correction', because another article from a different/independent entity has been issued. This is a rare thing - it's usually unlikely the publisher of a piece will reference an external work as a corrected work on their own piece. @TheTrustProject feels it is an excellent use case to encourage cross-linking between publishers.

Original article, MIT Tech Review: https://www.technologyreview.com/s/609771/a-cryptocurrency-without-a-blockchain-has-been-built-to-outperform-bitcoin/ (no correction made here)
Externally issued clarification/response/corrected article, MIT Media Lab: https://www.media.mit.edu/posts/iota-response/

(Here mainEntityofPage could be used to point to the original article in context, especially if no correction was made to the original article.)

<script type="application/ld+json"> 
{"@context":"http:\/\/schema.org",
	"@type":"AnalysisNewsArticle",
	"url":"https://www.technologyreview.com/s/609771/a-cryptocurrency-without-a-blockchain-has-been-built-to-outperform-bitcoin/",
..
..
"correctionComment": [ 
			{"@type":"Comment",
			"text": "A previous version of this story conflated information about willingness to take a pay cut and the amount willing to be taken.",
 			"datePublished" : "<Date>",
            “mainEntityofPage”:”https://www.technologyreview.com/s/609771/a-cryptocurrency-without-a-blockchain-has-been-built-to-outperform-bitcoin/",
            “externalCorrectedWork": "https://www.media.mit.edu/posts/iota-response/"
 			}
		    ]

“externalCorrectedWork" could also be "externalResponse" or "externalClarification".

This approach ends up proposing three new properties instead of the two we were going to help define.
correctionComment
correctedWork
externalCorrectedWork/externalResponse/externalClarification

Let us know your takes.

@danbri @vholland @thadguidry @chaals others: any comments on our post of three weeks ago? Would be good to bring this to closure.

For the most part this looks good to me. My only question is whether we should add externalCorrectedWork as a property of Comment or if we should create a subtype.

@danbri @thadguidry @chaals Thoughts?

⏯️🏠📴✈️⚠️🗽🛃➡️👣🚂🍽️🚿💤🌎🌞💻

@vholland @subbuvincent Seems like "externalCorrectedWork" is easier for publishers if it stays connected as a property of correctionComment as @subbuvincent example shows and he did actually mentioned it is "rare", so I'd keep as his example shows. Its kinda like "this correction comment is also about this externalCorrectedWork" ? hmm...about rears its head :)

+1 on correctionComment and correctedWork

I would also avoid a sub-type in this scenario.

Here is a quick summary proposal - deriving from @danbri's original proposal of Dec 18th, and today's comments from @vholland and @thadguidry.

• Add a new property called correctionComment
• subproperty of "comment"; domainIncludes CreativeWork; rangeIncludes: a Comment.
• Definition: "A comment summarizing corrections or errata in this version of a document, typically published in the document itself."
• Two new properties correctedWork and externalCorrectedWork. We need a domain-includes and range includes for this. @danbri @vholland @thadguidry @chaals, others, could one of you help with this?

And some proposed text definitions that could be edited down:

correctionComment
A comment recording a correction to an error in this version of a document, typically published in the document itself. The ‘text’ property is used to markup the actual correction text. Note: datePublished must be used to markup the date pertaining to when the correction was published. correctedWork must be used to markup the page or Creative Work that got corrected. See also externalCorrectedWork/externalResponse/externalClarification.

correctedWork
The Creative Work (or page or Article) that had an error and got corrected. This is used in conjunction with correctionComment which captures the text of the correction.

externalCorrectedWork
This is to be used in conjunction with correctionComment. When a different/separate entity publishes a Creative Work as a correction to a first work, or in response to, or as a clarification work, the publisher of the original work can point to the new work. Not to be confused with correctedWork which is the original publisher’s own work carrying a correction.

I am saying create a subtype of Comment. It seems weird to add externalCorrectedWork to Comment when the vast majority of Comments have nothing to do with corrections.

@subbuvincent ah, now I understand Vicki's point.... and I now agree with her.

Agreed with Vicki too. Thanks @vholland and @thadguidry.

Should I draft revised proposal to account for this? @danbri, would you like to weigh in?

@subbuvincent, please draft a revised proposal (and example). Thanks!

Before drafting a proposal, I thought let's re-do the same reference examples from earlier accounting for the proposed CorrectionComment sub-type. Are you folks OK with this? @vholland @thadguidry @chaals @danbri @TheTrustProject ?

1 Real example from a New York Times correction on an Oscars 2018 piece. The Trust Project considers this a regular journalism use case (the original article carries the correction in the UX, and there is no external correction offered/referenced)

<script type="application/ld+json">
{"@context":"http:\/\/schema.org",
	"@type":"ReportageNewsArticle",
	"url":"https://www.nytimes.com/2018/01/23/movies/oscars-snubs-surprises.html",
	"publisher": ...
	"datePublished": ..
	"dateModified": ..
	"headline":"...
	"mainEntityOfPage":"https://www.nytimes.com/2018/01/23/movies/oscars-snubs-surprises.html",
"correctionComment": [ 
		       {"@type":"CorrectionComment",
			"text": "An earlier version of this article misstated the number of times Denzel Washington has been nominated for an Oscar. His nod for “Roman J. Israel, Esq.” brings the total to nine, not eight.",
 			"datePublished" : "2018-01-23”,
	                “correctedWork”:”https://www.nytimes.com/2018/01/23/movies/oscars-snubs-surprises.html"
         		}
		    ]
}

2 Real example from the MIT Tech Review, which a different MIT body - the MIT Media Lab posted a response to.

<script type="application/ld+json"> 
{"@context":"http:\/\/schema.org",
	"@type":"AnalysisNewsArticle",
	"url":"https://www.technologyreview.com/s/609771/a-cryptocurrency-without-a-blockchain-has-been-built-to-outperform-bitcoin/",
..
..
"correctionComment": [ 
			{"@type":"CorrectionComment",
			"text": "A previous version of this story conflated information about willingness to take a pay cut and the amount willing to be taken.",
 			"datePublished" : "<Date>",
            “mainEntityofPage”:”https://www.technologyreview.com/s/609771/a-cryptocurrency-without-a-blockchain-has-been-built-to-outperform-bitcoin/",
            “externalCorrectedWork": "https://www.media.mit.edu/posts/iota-response/"
 			}
		    ]
}

One addition:

@TheTrustProject prefers we name 'externalCorrectedWork' to 'externalResponse' or 'externalClarification' without any change in definition or value taken. This is to avoid conflation in meaning that external parties are 'correcting' the first publisher's work. They just issue their own response work. When the first publisher corrects the original work, that is captured in 'correctedWork'.

<script type="application/ld+json"> 
{"@context":"http:\/\/schema.org",
	"@type":"AnalysisNewsArticle",
	"url":"https://www.technologyreview.com/s/609771/a-cryptocurrency-without-a-blockchain-has-been-built-to-outperform-bitcoin/",
..
..
"correctionComment": [ 
			{"@type":"CorrectionComment",
			"text": "A previous version of this story conflated information about willingness to take a pay cut and the amount willing to be taken.",
 			"datePublished" : "<Date>",
            “mainEntityofPage”:”https://www.technologyreview.com/s/609771/a-cryptocurrency-without-a-blockchain-has-been-built-to-outperform-bitcoin/",
            “externalResponse": "https://www.media.mit.edu/posts/iota-response/"
 			}
		    ]
}

I propose that we take the most basic and simple idea here, which seems to rough consensus, and implement that in our Pending area. This is the idea of a "correction" and a "CorrectionComment". Moving beyond this, there are a lots of possible elaborations, some of which touch wider areas than news, eg. ScholarlyArticles, annotation-like systems etc. So, @subbuvincent can you open an issue dedicated to that?

ping @subbuvincent

Am of the opinion that backstory would also be useful to an event, to describe what has lead up to this event.

We use BackgroundNewsArticle for that purpose in news, so Backstory could create some confusion.

A backstory as part of a news article does not define the entire article to have news background as its main topic. One might write an article about a recent event, but add to it some background of things wich previously happened.

backstory as part of an article is not the same as an article wich provides background as its main intent.

But by your coment alone, you do prove confusion is easy with the current vocab. A clear description of what exactly a backStory is will be needed.

@Meteor0id Just using a narrow property such as backStory to link to an Article, or any other CreativeWork type, to and Event (or any other type of Thing) that it is about would be far too restrictive.

We already have the subjectOf property that can satisfy this need.
eg.

<div itemscope itemtype="http://schema.org/Event">
  <h2 itemprop="name">Some Event</h2>
  <span itemprop="description">Something is going to happen</span>
  <a itemprop="subjectOf" href="https://en.wikipedia.org/wiki/Article_about_something_happening">More Info</a>
</div>

I came from here:
https://pending.schema.org/knowsLanguage

And can we change it to knowsLanguages and then accept an array of string?
We are working on this list of libre software hoster:
https://libreho.st/directory.json
And for now, we use communicationLanguages, but yeah, we'll switch.
(we are discovering schema.org ;) )

@pierreozoux , seems to me the plural could be assumed.

Thanks.
In general software development, when you have a plural, you know that you can put an array, without plural, then you have to post an issue like I just did. Is there some guidelines about plural and array? I think it would make sense to use plural when you can receive an array.

Coming from the fact that there are no requirements, within Schema.org, on the cardinality of properties. ie. Any property can in principle be repeated. The convention is that both Type names and Property names are singular.

Dependant on the data serialisation used such repetition can be more or less easily be represented as an array. JSON-LD being the most obvious:
"knowsLanguage": "en",
or
"knowsLanguage": ["en","fr"],

(Yes, there are a small number of exceptions to this convention but they are examples of early implementations that were far too well established, when cleanups were undertaken, to change)

This issue is being tagged as Stale due to inactivity.