Consider slightly relaxing the semantics around "abstract" and not be specific to schema:Article. See also: #228 (comment)

There is more discussion in the old pull request at #228, but let's continue here.

From a quick look back at the discussion my sense is that the notion of a structured abstract is what adds complexity here. In a schema.org setting there are two obvious ways to do that: by having property values be markup (easier in RDFa, feasible in JSON-LD, tricky in Microdata), and by using more graph/triple-based entities.

@sballesteros - can you summarize what's going on in science-periodicals/ontology#4 ? Did you go off the idea of a structured abstract?

Where the Scholarly Article ontology is concerned, we still need to support structure at the abstract level — the reason it isn't moving much is because we're hoping to just use schema.org and align :)

One use case that hasn't (to my knowledge) been discussed in these issues is that of capturing language information about an abstract. The reason for this is that it is common for articles written in non-English languages to have a same-language abstract and an English abstract (in some cases there can be more).

Where this runs into trouble is that even simple, single-paragraph abstracts need to contain some markup (emphasis, strong, possibly some maths). However, the RDF data model forbids rdf:HTML (and in fact anything but the dumbest literals) to sport language information. It's a rather daft limitation, but AFAICT it's not going away. There are various hacks that one can resort to, but none are really any good.

Because of this, even in cases when we are not facing abstracts with structured subsections, it would be most useful to have a schema:abstract (or broadened schema:description) containing some subtype of CreativeWork so that it could be given at the very least an schema:isLanguage.

I'll let @sballesteros speak to the broader subsections issue.

Still would love to be able to support structured abstracts (right now we are just using schema:description for the abstract).

This is the latest of what we were thinking:

• 1 new class: Abstract (subClassOf CreativeWork)
• Adding CreativeWork to the range of description or adding 1 new property: hasAbstract (domain: CreativeWork, range: Abstract)

Structured abstracts can then simply leverage the hasPart property of CreativeWork.

Example:

{
  "@type": "ScholarlyArticle",
  "hasAbstract": { // or description
    "@id": "http://example.com/abstract",
    "@type": "Abstract",
    "hasPart": [
      {
        "@id": "http://example.com/abstract#Methods",
        "@type": [ "Abstract", "http://purl.org/spar/deo/Methods" ],
        "name": "Methods",
        "text": "We used ..."
      },
      {
        "@id": "http://example.com/abstract#Results",
        "@type": [ "Abstract",  "http://purl.org/spar/deo/Results" ],
        "name": "Results",
        "text": "We found ..."
      }
    ]
  }
}

Not super happy with hasAbstract but it is to avoid abstract / Abstract which is discouraged by schema.org and seems to be a "pattern" (e.g hasDigitalDocumentPermission and DigitalDocumentPermission).

Adding CreativeWork to the range of description would remove the need for an hasAbstract property. I kind of like this solution (no metaphysical issue of what is the difference between an abstract and a description) but it is probably a bit too wild?

FWIW adding CreativeWork to the range of description is my favourite option here 🍦

I was looking at the Google Knowledge graph API and noticed that they use detailedDescription (see http://schema.googleapis.com/detailedDescription). That would work pretty well instead of bumping the range of description or adding a hasAbstract prop.

Does anyone have an objection to just reusing Google's detailedDescription here? At our end we've pretty much stretched reuse of description beyond usefulness or recognisability and are looking at just adopting that instead.

http://schema.org/Thing also has http://schema.org/disambiguatingDescription ...

Issue with disambiguatingDescription is that the range is schema:Text as opposed to schema:CreativeWork (goog:detailedDescription)

yeah, maybe we could fix that. I'd like to minimize use of goog-specific terms if we can. I think that one was added at Google for the Google KG API but I forget, maybe @vholland can advise?

My understanding is that disambiguatingDescription is completely different, it is meant to mark up "TV Series" in "Buffy (TV Series)", as in Wikipedia. I don't think it's a great idea to conflate the two. What this issue is about is more powerful descriptions, and since there's a goog extension the wild that seems to be a perfect match why not use it?

@darobin So in summary... your using description for a "short description" and would like a property for "much longer description" ? (voiding anything about "abstract" or not and focusing instead on the actual applicability of your needs here)

As @darobin said, the intent of disambiguatingDescription was to add short phrases ala Wikipedia to disambiguate similarly named entities.

At Google, we have been experimenting with the property detailedDescription, described as:

An article which is a detailed description of the entity. The entity should be the primary focus of the article.

It's range is schema.org/Article, but I don't see why it could not be schema.org/CreativeWork instead.

@thadguidry It's not so much that as the fact that description is Text, whereas an abstract is more structured (sometimes a lot more so) and makes sense as a CreativeWork (since it may have a title, different authors, languages, etc.). Based on this discussion overloading description for that feels like the wrong option.

@darobin OK, so since your need is really for dealing with Abstracts better and in having and providing structure FOR Abstracts...then the only way to solve that is with

👍 for adding a new class: Abstract (subClassOf CreativeWork)

If we're going to create a new type, let's call it what it is: StructuredAbstract.

I'd actually just prefer ... that we intend for the real reasoning behind it all... abstacting a CreativeWork (summarizing) ...so...

CreativeWorkAbstract

is a subtype and in the end, we are simplifying data about any CreativeWork.
@dbs (with your library hat on) what do you think ?

Not all abstracts are structured abstracts, so StructuredAbstract makes perfect sense to me. Ordinary abstracts are just text.

@thadguidry as far as I can see the proposal is that it abstracts a ScholarlyArticle, not any CreativeWork. That seems the scope for which structured abstracts are a significant type of thing.

I quite like hasAbstract as a property of ScholarlyArticle (excepting the name) as it would cut out some ambiguity and graph hopping when looking for abstracts.

If we agree that there is a use case to provide a CreativeWork as value for things that fall under the broad category of schema:description then I think that a property of the level of generality of detailedDescription is better suited than abstract as the use case is of interest for more creative works than just articles (Audio, Video, etc). It may be worth considering starting with that and then adding sub properties when needed (and ask ourselves if we really need an abstract subproperty should we already have access to description and detailedDescription ?).

With that in mind, for the abstract use case we would have:

"detailedDescription": {
  "@type": "WorkAbstract"
  ...
}

taking advantage of the new WorkAbstract class proposed by @RichardWallis .

And, for the knowledge graph API use case:

"detailedDescription": {
  "@type": "Article"
  ...
}

@darobin I shouldn't have generalised with 'mostly likely'. You are correct.

@sballesteros The idea of an 'abstract' or 'summary' of some resource is not novel and already exists in the wild. I think we agree that it differs from description, title/label of some resource. It sits somewhere in between. How people use abstract in practice may of course vary quite a bit. Having 'abstract' is not competing with a more complex and structured Abstract. I'd like to see both cases covered. And prefer not to hop around another resource to get to a simple abstract/summary.

Ping. Are we all still awake? :)

Focusing only on the core aspect of this issue ie adding abstract property, did we cover what we needed to cover? Do we agree that an abstract can have a Text, URL, and/or ExampleClass range?

IMO, a follow-up issue can address what's discussed here regarding structured abstracts: do we need a different (sub)property and class for structured/detailed abstracts?

The reason I prefer to separate these issues is because AFAIK we don't have a single schema for structured abstracts, so I'm hesitant to see that this issue covers everything all at once. I suspect that different research disciplines have their own structures, and different communities would have their own expectations going forward. Can we do this incrementally without over-specifying up front?

Any objections to adding "abstract" as a sub-property of "description"?

( We can come back to structured text, markup etc separately.)

@danbri Why not a sub property of "article"? is it because abstracts are broader than articles? Are we saying that a movie trailer is not an abstract of a movie (film)? I have never considered an abstract to be a type of description, though I guess it sorta does a descriptive job.

abstract subPropertyOf description sounds good to me. dcterms has it as well.

to @HughP 's point - "article" is not a property. A sub-property of one property is another that means the same thing and then something extra too.

So we could say "abstract" is a property of a CreativeWork such as an Article, Book or other (typically written) work, which summarizes briefly the main content.

Ok, let's get this into our next release, for Sept 1st.

I had hoped to get it into this one (3.9) but felt duty bound, in my editorial capacity, to re-read this entire multi-year discussion to check we weren't missing anything. But maybe we can share that work?

We got bogged down with structured abstracts previously. Can we live with a text field only, for now? @csarven, you asked also for URL values. What would they point to?

So, how about this:

• a new property, "/abstract", subPropertyOf "description".
• rangeIncludes: Text; domainIncludes: CreativeWork
• definition: "An abstract is a short description that summarizes a CreativeWork."

We should collect up the usecases that are not addressed by this, too

I can certainly live with Text for now. I've asked for URL as well because I figured that will make it possible for structured abstracts to be worked in later (through a separate issue). Are there any particular issues to add the URL later along with the notion of a structured abstract if/when that's ready?

+1 to the proposed property characteristics.

ok, I've committed a definition, and am republishing our editorial/drafting site on the webschemas domain... should be on https://webschemas.org/abstract in a few mins

@csarven we very often tweak the expected types associated with properties, so there's no need to anticipate all future developments at this moment. We prefer to do that than introduce lots of properties with overlapping meanings...

Please, don't use reserved programming language keyword for label of type or property 🙏

This issue is being tagged as Stale due to inactivity.

Some implementation report for the record:

I've been using schema:abstract in some of the articles under https://csarven.ca/ since 2015.

dokieli is a clientside editor for decentralised article publishing, annotations and social interactions: https://dokie.li/ . Its UI allows users to embed statements with this property in documents.

The W3C Linked Data Notifications spec: https://www.w3.org/TR/ldn/ also includes schema:abstract ;)

I'm in the process of adding semantics to my publications list on website. schema:abstract would be more suitable there in addition to having a one-liner using schema:description. It would also be more suitable for longer publications on the web and scholarly articles. I support adding this to the vocabulary.

I've come around to being in favour of the addition of schema:abstract, but it needs some examples that incorporate schema:description as well so that people can clearly distinguish the purposes of the two properties.

Those examples could also show up under schema:description, of course, which would help lead people to the new schema:abstract property.

some examples that incorporate schema:description as well so that people can clearly distinguish the purposes of the two properties.

Regarding this article, schema:description could be "discussion on adding abstract property to schema.org" and schema:abstract could be: "This thread discusses the addition of an abstract property in addition to the existing description property. There is an existing PR (#228) which lists previous discussion on this topic. Current summary includes making abstract a sub-property of description and clarifying the differentiation between the two." In terms of semantics, description describes some artefact, and abstract provides an overview (or abstraction) of an artefact.

@coolharsh55 I understand the distinction, having been involved in the discussions since the PR, but most webmasters (or anyone who hasn't delved into this repository) will not. That's one of the main reasons for (and the value of) examples in schema.org : they help codify the usage of the classes and properties.

More implementation reports: using it now for all blog posts, articles, and publications on https://ruben.verborgh.org/. 338 occurrences in total.

In case other examples of use are valuable, I use abstract as part of a pyramid content hierarchy (headline, description, abstract) throughout Earth.Org.UK, eg see:

https://www.earth.org.uk/note-on-site-technicals-13.html

Aside: what's a good way to find out how many pages/sites are using various parts of the schema? How weird am I to be doing this? B^>

Rgds

Damon

As SEO point of view, What is the character limit while writing abstract in schema?

If that's a question to me: I don't know. Mine tend to run as long as a few sentences. Search engines are probably not treating them much different than un-marked-up text at least for now is my guess.