How should schema.org relational properties be interpreted? - schema.org

I am currently looking into schema.org to use it with API platform, but there are certain properties that I don't understand.
Let's take https://schema.org/Organization for example:
A Thing (and this case an Organization) has properties, like a name and an address. Now what I don't understand is the property department. However in real life an organization doesn't have just a single department; it has several at least.
Shouldn't that property be oneToMany?
Or do I not understand it and does department link to the parent company, which makes the child Organization (the one with the department property) a department? But if that was to be the case I'd think there would be a Department object instead (extending from the Organization object).
When I define this property in my API Platform's schema.yaml, it expects a single value, just like I would expect from the schema.org's documentation.
Am I missing something? Can someone please explain how I should interpret and use such properties?
Edit: I found out that API Platform expects every property to have a single value, unless specified otherwise. So I have to setup the department property to be oneToMany.
That combined with the great explanation below (the accepted answer) explains it all.

All Schema.org properties can have multiple values. Usually it doesn’t make sense for every property (e.g., birthDate), but it’s possible anyway.
For the department property, the domain (the item which has this property) is the parent organization, and the range (the item which is the value of this property) is the department. In cases like this, where the domain and range expect the same types, you have to interpret the textual definition to make sure for which "direction" the property is intended.
(If, for some reason, you can’t provide multiple values for a property, note that you can use every Schema.org property in the other direction, too, even if no inverse property is defined.)
Examples
An organization (#1) has two departments (#2, #3).
JSON-LD
Using an array ([]):
{
"#context": "http://schema.org/",
"#type": "Organization",
"#id": "#1",
"department": [
{
"#type": "Organization",
"#id": "#2"
},
{
"#type": "Organization",
"#id": "#3"
}
]
}
Microdata
Repeating the property:
<div itemscope itemtype="http://schema.org/Organization" itemid="#1">
<div itemprop="department" itemscope itemtype="http://schema.org/Organization" itemid="#2"></div>
<div itemprop="department" itemscope itemtype="http://schema.org/Organization" itemid="#3"></div>
</div>
RDFa
Repeating the property:
<div typeof="schema:Organization" resource="#1">
<div property="schema:department" typeof="schema:Organization" resource="#2"></div>
<div property="schema:department" typeof="schema:Organization" resource="#3"></div>
</div>

Related

copyright information for image repositories (schema.org, json-ld)

This is not exactly a technical question, it's about understanding the elements of CreativeWork and ImageObject in schema.org.
When creating structured data for an image, there are some attributes I can use to convey the copyright information, notably:
creator
copyrightHolder
license
This looks quite straightforward for me (even considering the legal differences of "copyright" in the Anglo-American and European worlds).
What I'm looking for is how to include the copyright information from pictures bought on image repositories like iStock. The information provided looks like: istock.com ©acreator ID-000000000.
How is this information meant to be used with schema.org?
As copyrightHolder is meant to be a Person or Organization, using the string 'istock.com ©someone' as the person's or organisation's name doesn't seem to be the right thing to do.
So I came up with this JSON-LD code:
[
{
"#context": "https://schema.org",
"#type": "ImageObject",
"contentUrl": "https://path/to/my/image",
"copyrightHolder": {
"name": "istock.com"
},
"creator": {
"name": "someone"
},
"copyrightNotice": "istock.com ©acreator ID-000000000",
"license": "https://www.istockphoto.com/en/legal/license-agreement"
}
]
I'm still not sure where to put the ID of the image, and also I'm not happy using the id on istock.com as "name" attribute for "creator".
I could also only use the copyrightNotice and not use "creator" and "copyrightHolder" but I'm not sure if I'd meet the legal requirement then.
The schema.org information not really related to any legal requirement issues (It is vocabulary for search engines).
The credit should be visible to the user (With -or- Without schema) if the license requires adding a credit (Who is the copyrightHolder VS creator also not related to schema.org).
More important:
Don't mark up content that is not visible to readers of the page. Google Guidelines
So only add structured data that visible to the users. I guess you don't have in your web design clickable text to istock license (So you don't need to add this).
Even creditText could be enough.
Example (The markup visible to readers):
Basic example - Withtout
<img src="italy-beach.jpg" alt="italy beach."/>
By Jane Doe
copyrights istock.com. Author Leonardo
Basic example - With
<div itemscope itemtype="https://schema.org/ImageObject">
<img src="italy-beach.jpg"
alt="italy beach."
itemprop="contentUrl" />
By <span itemprop="author">Jane Doe</span>
copyrights <span itemscope itemtype="https://schema.org/Organization" itemprop="copyrightHolder"><span itemprop="name">istock.com</span> Author: <span>Leonardo</span>
</div>
image id
You can use https://schema.org/identifier.

What is the correct hierarchical schema.org markup for a category page of articles?

I am working on a section of a website that is a combination of 'how-to' articles and 'faq' articles. When excerpted groups of those articles are displayed in a list by category I am not sure what schema to use for the container and the individual articles. Blog and BlogPosting is for blogs and this is not a blog. The articles are not dated or in chronological order. So I am thinking each one is either 'CreativeWork' or 'Article'. But I am not sure what the container's schema should be when they are displayed in excerpted groups or categories.
Edit:
Just to clarify.
Here's a simple version of my markup:
<div itemscope="" itemtype=" ??????? ">
<article itemscope itemtype="http://schema.org/Article"></article>
<article itemscope itemtype="http://schema.org/Article"></article>
<article itemscope itemtype="http://schema.org/Article"></article>
</div>
Firstly don't get too hung up on lists they are not as important [to the machine] as you think.
Try identifying the categories as well as you can. Not having a view into your world, I'll pick a couple of random categories "World War II" & "Europe". Create a page for each (quite possibly these could be your current list pages) and add the Schema.org specific to the category term itself.
{
"#context": "http://schema.org",
"#type": ["Place","DefinedTerm"],
"#id": "http://example.com/concepts/europe",
"name": "Europe",
"sameAs": "http://www.wikidata.org/entity/Q46",
....
{
"#context": "http://schema.org",
"#type":"DefinedTerm",
"#id": "http://example.com/concepts/wwii",
"name": "World War II",
"sameAs": "http://www.wikidata.org/entity/Q362",
....
Then for your articles use the "about" property to reference them to the categories:
{
"#context": "http://schema.org",
"#type":"Article",
"#id": "http://example.com/articles/A123",
"name": "World War II in Europe",
"about": ["http://example.com/concepts/wwii",
"http://example.com/concepts/europe"],
.....
That in theory is all you need to do for the crawler, which should have crawled all your pages, to understand you articles and what they are about.
If you want to be a bit more explicit, on the category pages you could add in the reverse relationships using the subjectOf property:
"subjectOf": ["http://example.com/articles/A123",
"http://example.com/articles/A033"],
Lists of things are of more use to humans, whereas in the machines (eg. The Knowledge Graph) they can work it out from the relationship information you provide.

How to define multiple dietary restrictions in suitableForDiet field? [duplicate]

A Schema.org object of type Person can have a sameAs property of type URL. According to Google's structured data site, the sameAs property can be a single item or an array.
The docs on Schema.org do not mention whether sameAs can be a single item or an array. Is this just Google deviating from Schema.org? Or is it the case that all properties in Schema.org can be single items or arrays?
Every Schema.org property can have multiple values. It doesn’t necessarily make sense for some properties (e.g., birthDate), but it’s still allowed.
In JSON-LD:
"sameAs": ["/foo", "/bar"],
In Microdata:
<link itemprop="sameAs" href="/foo" />
<link itemprop="sameAs" href="/bar" />
In RDFa:
<link property="sameAs" href="/foo" />
<link property="sameAs" href="/bar" />
This doesn’t necessarily mean that Google (or any other consumer) supports this for every property, too. So when Google explicitly mentions this in their documentation, you can be sure that the respective search result feature works with multiple values.

Google does not correctly merge microdata and json+ld in the same page using same URI id

I have a product page with "microdata" and "json+ld" codes. Both of the codes refers to the same #id URI object (http://www.example.org/product#this) so I would expect to "mix/merge" both properties, but instead structured data testing tool shows 2 "individual" products so....
1- Does Google support using two syntax in the same page?
2- Is this well implemented? Can I refer two codes to the same object using itemId for microdata and #id for json+ld?
3- Can this damage my page in terms of structure data indexing?
thanks
You can check it out using this code in test tool:
<div itemscope itemtype="http://schema.org/Product" itemid="http://www.example.org/product#this">
<a itemprop="url" href="http://www.example.org/product">
<div itemprop="name"><strong>Product Name</strong></div></a>
<div itemprop="description">Product Description</div>
<div itemprop="brand" itemscope itemtype="http://schema.org/Organization"><span itemprop="name">Product Brand</span></div>
<div itemprop="offers" itemscope itemtype="http://schema.org/Offer"> <span itemprop="price">100</span><link itemprop="itemCondition" href="http://schema.org/NewCondition" /> New</div>
</div>
<script type="application/ld+json">
{
"#context": "http://schema.org/",
"#id": "http://www.example.org/product#this",
"name": "Product Name",
"#type": "Product",
"image": "http://www.example.com/anvil_executive.jpg",
"mpn": "925872",
"brand": {
"#type": "Thing",
"name": "ACME"
},
"offers": {
"#type": "Offer",
"priceCurrency": "USD",
"price": "119.99",
"itemCondition": "http://schema.org/UsedCondition",
"availability": "http://schema.org/InStock"
}
}
</script>
My guess would be that Google’s Structured Data Testing Tool doesn’t support this for different syntaxes, as it seems to work if using the same syntax. But as they still display the URIs correctly (http://www.example.org/product#this in both cases), you could argue that it’s just the tool’s interface that doesn’t merge them.
However, as far as I know Google does not document to support these subject URIs anyway (but this doesn’t necessarily mean that they don’t support it), so it might not matter for them.
Your example works fine if using http://linter.structured-data.org/: it creates one item with both brands and both offers.
While technically it is feasible to merge data coming from two different syntaxes (read microdata and json-ld) and the Structured Data Linter confirms so, Google does not support it, which means properties won't be merged (and won't satisfy Rich Snippets' requirements).
We have a final confirmation by several actors in the SEO World, including Dan Brickley and Jarno van Driel.
in general you can use both syntaxes side by side, but you won't get
the fine-grained merging of triples by ID that a pure RDF application
might expect (Dan Brickley on Twitter, Jan 14th, 2020, bold mine)
--
I think #danbri already was pretty clear. Highly doubt you'll get a
different answer from other Googlers. (Jarno van Driel on Twitter, Jan 14th, 2020)
The proposed solution so far is to parse the microdata and publish it as JSON-LD.

Proper format for Google Schema?

I've been experimenting with Google Schema and I've looked at a few code generators and they vary in design. The link I'm using for info for these examples: http://schema.org/Book
1) When is it proper to use itemscope itemtype="someSchemeURL.org" or an actual href?
Example:
<div itemprop="author" itemscope itemtype="http://schema.org/Person">
or
<div itemprop="bookFormat" href="http://schema.org/bookFormatType">
The second example isn't even valid HTML since the href attribute isn't accepted on a div.
2) For the example above, is the first column always an itemprop and the second column always the itemscope itemtype?
3) If there is no itemscope itemtype specified, does the itemprop default to the parent itemscope itemtype?
Example:
<div itemscope itemtype="http://schema.org/Book">
<div class="book" itemprop="name"></div>
<div itemprop="author" itemscope itemtype="http://shema.org/Person">
<div class="author" itemprop="name"></div>
</div>
</div>
The .author class will result in the name attributed to "author"
The .book class will result in the name attributed to "book"
So this would mean that although multiple itemprop's have the same name, the itemprop always applies to the parent element, correct?
4) Where is it specified when to use meta, link, span, or div? Or is this left up to preference?
Example:
<div>
<meta itemprop="datePublished" content="2013-07-01">
Some text
</div>
<div>
Some text
<link itemprop="bookFormat" href="http://schema.org/bookFormatType">Ebook
</div>
The second example is invalid, I know, but it's an example from one of the code generators. That specific generator produces invalid code so I know not to use it, but where are they getting their idea to use a link tag (albeit incorrectly)?
These docs can answer almost all of your questions. Maybe you've already seen them but just in case.
Microdata Spec
Getting Started Tutorial at Schema.org
So answers for your questions in order they appear:
1.The first one is correct. The official microdata spec tells us
Microdata is most useful, though, when it is used in contexts where
other authors and readers are able to cooperate to make new uses of
the markup.
For this purpose, it is necessary to give each item a type, such as
"http://example.com/person", or "http://example.org/cat", or
"http://band.example.net/". Types are identified as URLs.
The type for an item is given as the value of an itemtype attribute on
the same element as the itemscope attribute.
Example
<section itemscope itemtype="http://example.org/animals#cat">
<h1 itemprop="name">Hedral</h1>
<p itemprop="desc">Hedral is a male american domestic
shorthair, with a fluffy black fur with white paws and belly.</p>
<img itemprop="img" src="hedral.jpeg" alt="" title="Hedral, age 18 months">
</section>
2.No. Itemprop is used to indicate property of some entity. Itemscope - entity scope. And itemtype - type of the entity. These are different tags with different meaning which can be used separately (at least in theory). What doc says:
At a high level, microdata consists of a group of name-value pairs.
The groups are called items, and each name-value pair is a property.
Items and properties are represented by regular elements.
To create an item, the itemscope attribute is used.
To add a property to an item, the itemprop attribute is used on one of
the item's descendants.
And examples
<div itemscope>
<p>My name is <span itemprop="name">Elizabeth</span>.</p>
</div>
<div itemscope>
<p>My name is <span itemprop="name">Daniel</span>.</p>
</div>
3.Even when itemscope itemtype are specified along with itemprop it is still property of the parent type. In this case this property is entity itself. And you're correct with your example: names will go to different entities. Here is what doc says about processing properties.
The property value of a name-value pair added by an element with an
itemprop attribute is as given for the first matching case in the
following list:
If the element also has an itemscope attribute The value is the item
created by the element.
If the element is a meta element The value is the value of the
element's content attribute, if any, or the empty string if there is
no such attribute.
If the element is an audio, embed, iframe, img, source, track, or
video element The value is the absolute URL that results from
resolving the value of the element's src attribute relative to the
element at the time the attribute is set, or the empty string if there
is no such attribute or if resolving it results in an error.
If the element is an a, area, or link element The value is the
absolute URL that results from resolving the value of the element's
href attribute relative to the element at the time the attribute is
set, or the empty string if there is no such attribute or if resolving
it results in an error.
If the element is an object element The value is the absolute URL that
results from resolving the value of the element's data attribute
relative to the element at the time the attribute is set, or the empty
string if there is no such attribute or if resolving it results in an
error.
If the element is a data element The value is the value of the
element's value attribute, if it has one, or the empty string
otherwise.
If the element is a time element The value is the element's datetime
value.
Otherwise The value is the element's textContent.
The URL property elements are the a, area, audio, embed, iframe, img,
link, object, source, track, and video elements.
4.Left up to preference. There is general advice from search engines - markup consumers
However, as a general rule, you should mark up only the content that
is visible to people who visit the web page and not content in hidden
div's or other hidden page elements.
Schema.org doc gives good overview when usage of hidden elements may make sense.
Many pages can be described using only the itemscope, itemtype, and
itemprop attributes (described in section 1) along with the types and
properties defined on schema.org (described in section 2). However,
sometimes an item property is difficult for a machine to understand
without additional disambiguation. This section describes how you can
provide machine-understandable versions of information when marking up
your pages.
Dates, times, and durations: use the time tag with
datetime
Enumerations and canonical references: use the link tag with
href
Missing/implicit information: use the meta tag with content.
Check this link for details.