Adds abstract property to Article

[danbri]

http://schema.org/Article

There is a proposal - see discussion in #228 - that we should add an 'abstract' property, rather than use 'description' for everything.

[csarven]

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

[danbri]

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?

[darobin]

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.

[sballesteros]

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?

[darobin]

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

[sballesteros]

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.