schemaorg: Example contains 'author' property with text value (which is not expected)

think blog post rather than a 3rd volume of a scholarly compendium…

CreativeWork is a super-type for far more than blog posts, think Book & Article. You cannot constrain the discussion of the ramifications of this to only one area of sub-types .

I am far from convinced that the edge-case benefits (for people who cannot get their head around using a Person and/or a string for the author property) of this proposal overcome the potential anomalies and confused practice it could introduce.

From the info-factoring document @danbri references "The only problem with this method is that it requires a lot of intelligence in the reader or user of the metadata to interpret the meaning of fields which occur more than once. " Multiple occurrences of authorName have no way to distinguish if they are different individuals or pseudonyms of a single person, or a combination thereof.

You underplay the prevalence of multiple author creative works. For blog posts and works of fiction I agree it is unusual; in non-fiction it is more common; technical/academic non-fiction yet more common; for scientific/academic articles it is very common.

In referencing names of other types I was not implying that they often have multiple names.
The point I was trying to make was that this [authorName] case, if adopted, would establish a new vocabulary pattern whereby at text property is introduced that duplicates the core capability within Schema.org for all properties to to accept a Text value. Having introduced it, it would be difficult to reject similar proposals in other areas.

I am still -1 on this

My [counter]proposal would be to explicitly add Text to the range of author. Plus ensure that we show a mixture of examples with Text and Person references.

This issue is being tagged as Stale due to inactivity.

I think you balancing on the tip of a significant iceberg here. We are discussing a potential individual property but there are further ramifications as to a) The future general development direction, and b) how it would be used.

Are you saying that you want to move towards a point where the following statement would not be true?

We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string, even if our schemas don’t formally document that expectation.

If you are that is a really significant shift.

As to the use of the proposed authorName property, as I said earlier, it raises many questions about its application beyond the the simplistic author of a blogpost case, that I can see causing confusion.

I don’t believe @unor is lacking knowledge.

The point I was trying to make was that this [authorName] case, if adopted, would establish a new vocabulary pattern whereby at text property is introduced that duplicates the core capability within Schema.org for all properties to to accept a Text value

Yes, I would like to gently move us away from that expectation, at least for common cases. I have seen no evidence that it is dealt with gracefully by the search engines. The flagship example by far is that it allows compact markup for the names of authors, so if we address that usecase (and eventually perhaps a handful of others) we could nudge the “strings instead of things” hack/heuristic back into being an exotic cornercase instead of a core claim for how schema.org should be consumed.

On the surface the simple proposal for authorName looks attractive.

However in practice I can see it causing some issues. All fine for a single author that you do not have a URL for.

I can already hear the questions incubating for situations that are not so simple:

• I have a URL, should I use authorName as well?
  • … and if I do, what about more than one, how do I associate each authorName with its relevant author?
• If I add two authorNames does that mean two names for the same author (Richard Bachman & Stephen King), or two different authors?
• If you have authorName, what about publisherName, characterName, providerName, sponsorName, translatorName? Or itemOfferedName on Offer, or eventName on Organization & Place, or deathPlaceName on Person.

I know I have gone a bit extreme on that last one, but I see this as potential slippery slope towards string based degradation in the ability to describe relationships between Things.

Is this a necessary introduction of a duplicate way of identifying the same information when “some types such as Role and URL can be used with all properties” anyway.

I agree there needs to be more guidance/examples encouraging the use of URLs when available but showing strings when not, but a text based authorName gets a -1 from me.

authorName is potentially useful for authors using pseudonyms. For example, saying Richard Bachman is an alias for Stephen King is not nearly as useful as saying the authorName is “Richard Bachman” while the author is a schema.org/Person named Stephen King.