-
Notifications
You must be signed in to change notification settings - Fork 823
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds abstract property to Article #276
Comments
Consider slightly relaxing the semantics around "abstract" and not be specific to |
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 Because of this, even in cases when we are not facing abstracts with structured subsections, it would be most useful to have a 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 This is the latest of what we were thinking:
Structured abstracts can then simply leverage the 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 Adding |
FWIW adding |
I was looking at the Google Knowledge graph API and noticed that they use |
Does anyone have an objection to just reusing Google's |
Issue with disambiguatingDescription is that the range is |
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 |
@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 At Google, we have been experimenting with the property
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 |
@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) |
Can we have a more descriptive name (than Abstract)?
guha
…On Tue, Dec 6, 2016 at 1:34 PM, Thad Guidry ***@***.***> wrote:
@darobin <https://github.com/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)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#276 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFAlCtF89NtWxsFPd6HUF82OXDA-ru6Sks5rFdT9gaJpZM4DV_Mn>
.
|
If we're going to create a new type, let's call it what it is: StructuredAbstract. |
We should discuss that.
Another possibility is ArticleAbstract. Just don't want it to be confused
with the many Abstract X (such as Abstract Class). Just being super careful
guha
…On Tue, Dec 6, 2016 at 2:00 PM, Dan Scott ***@***.***> wrote:
If we're going to create a new type, let's call it what it is:
StructuredAbstract.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#276 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFAlCmnPVBUn-7i6zX-_lyXVv10_rXNrks5rFdsNgaJpZM4DV_Mn>
.
|
Yes, *Abstract* is a dangerously generic word.
StructuredAbstract does describe the type of ’Thing’ it would be.
This definition <http://www.medilexicon.com/dictionary/327> kind of sums it
up:
Summary description of a published paper, *or other document,* in which
information about the study reported in the paper is set out in a
systematic, stylized form with separate paragraphs broken down under
headings such as aims, methods, main outcome measures, results,
conclusions. *[My insert]*
ArticleAbstract is another good candidate with a similar definition, unless
there are other abstracts of documents, that are not articles, that we
would want to encompass with this.
~Richard
Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Linkedin: http://www.linkedin.com/in/richardwallis
Twitter: @rjw
…On 6 December 2016 at 22:02, R.V.Guha ***@***.***> wrote:
We should discuss that.
Another possibility is ArticleAbstract. Just don't want it to be confused
with the many Abstract X (such as Abstract Class). Just being super careful
guha
On Tue, Dec 6, 2016 at 2:00 PM, Dan Scott ***@***.***>
wrote:
> If we're going to create a new type, let's call it what it is:
> StructuredAbstract.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#276#
issuecomment-265286515>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AFAlCmnPVBUn-7i6zX-_
lyXVv10_rXNrks5rFdsNgaJpZM4DV_Mn>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#276 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AHVdIOUBsw49hBv9UGBav1pjA9zvpV4dks5rFduEgaJpZM4DV_Mn>
.
|
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. |
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 With that in mind, for the abstract use case we would have:
taking advantage of the new And, for the knowledge graph API use case:
|
@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.) |
Good idea!
… Am 27.06.2019 um 14:36 schrieb Dan Brickley ***@***.***>:
Any objections to adding "abstract" as a sub-property of "description". We can come back to structured text, markup etc separately.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
@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:
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 🙏 |
there are too many programming languages for this to be feasible
…On Sat, 19 Oct 2019 at 23:22, Fabrice Theytaz ***@***.***> wrote:
Please, don't use reserved programming language keyword for label of type
or property 🙏
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#276?email_source=notifications&email_token=AABJSGOKLHBMEOSHJ75QL2LQPOCCRA5CNFSM4A2X6MT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBX523Q#issuecomment-544202094>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABJSGJ65IP75CBH7DO7BN3QPOCCRANCNFSM4A2X6MTQ>
.
|
This issue is being tagged as Stale due to inactivity. |
Some implementation report for the record: I've been using 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 |
I'm in the process of adding semantics to my publications list on website. |
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. |
Regarding this article, |
@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. |
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.
The text was updated successfully, but these errors were encountered: