Using Schema.org for extension plugin info - schema.org

I've browsed the web for quite some time now, and have a good grasp on how Schema.org works. Now, it comes to mind that one could use Schema.org to let search engines know that this or that website is using particular software on the website, given that some functionality is provided to it. On the other hand, I can't find any references of major players doing so (WordPress, WooCommerce, Magento), so I was wondering:
How would I mark my piece of software, using Schema.org, on customer's website?
What exactly can I add as info to it (name, author, URLs, desc)?
Which types/properties should be used?
To add to point question 3, SoftwareApplication seems pretty much like something that would cover it. In Schema.org’s own examples, like following:
{
"#context": "http://schema.org",
"#type": "Restaurant",
"name": "Tartine Bakery",
"potentialAction": {
"#type": "ViewAction",
"target": [
"http://www.urbanspoon.com/r/6/92204",
{
"#type": "EntryPoint",
"urlTemplate": "http://api.urbanspoon.com/r/6/92204",
"contentType": "application/json+ld"
},
"android-app://com.urbanspoon/http/www.urbanspoon.com/r/6/92204",
{
"#type": "EntryPoint",
"urlTemplate": "urbanspoon://r/6/92204",
"actionApplication": {
"#type": "SoftwareApplication",
"#id": "284708449",
"name": "Urbanspoon iPhone & iPad App",
"operatingSystem": "iOS"
}
},
{
"#type": "EntryPoint",
"urlTemplate": "urbanspoon://r/6/92204",
"actionApplication": {
"#type": "SoftwareApplication",
"#id": "5b23b738-bb64-4829-9296-5bcb59bb0d2d",
"name": "Windows Phone App",
"operatingSystem": "Windows Phone 8"
}
}
]
}
}
Schema.org is used to provide info about an restaurant (why not software?). So, if anyone has an idea of how can this be done, it would be much appreciated.

Schema.org doesn’t offer a property to specify the SoftwareApplication that was used for generating a WebSite/WebPage.
The isBasedOn property might be used, given its broad definition ("A resource that was used in the creation of this resource."), but I guess it was not intended for this purpose.
Instead of specifying the software that is used for generating the pages (which is typically not interesting for consumers, especially since it doesn’t necessarily follow that certain features are available), it might make more sense to specify the potential actions offered by the site/pages:
RegisterAction
CommentAction
SearchAction
BuyAction
etc.
And from such an Action, you could use (where applicable) the target property to specify an EntryPoint which can specify with actionApplication which software is used to "complete the request".
(By the way, you can specify the software that was used to generate the HTML document as meta tag, no need for structured data: generator)

Related

"Unspecified Type" in Structured Data Testing Tool

I have recently written json schema for my client's local business with multiple locations. I have run it through Google's Structured Data Testing Tool, but I have noticed that it is defined as "unspecified type" rather than LocalBusiness.
I am also trying to implement this schema onto my client's WordPress site via Google Tag Manager and it has not seemed to work (I am guessing that this is because it is unspecified type rather than LocalBusiness?).
You didn’t post your JSON-LD, but from the output of Google’s SDTT, I would guess that this is the reason:
You’re using graph instead of #graph. Without the #, it gets interpreted as a Schema.org property (which doesn’t exist), not as a way defined in JSON-LD to provide multiple top-level items.
So instead of something like
{
"#context": "http://schema.org",
"graph":
[
{
"#type": "Organization"
},
{
"#type": "LocalBusiness"
}
]
}
you need to have something like
{
"#context": "http://schema.org",
"#graph":
[
{
"#type": "Organization"
},
{
"#type": "LocalBusiness"
}
]
}

Schema.org Accommodation with price?

I'm attempting to add a schema for an Accommodation, but I can't seem to find a way to reference the 'offer' or 'price' to this schema. Im using JSON-LD to format this schema.
I have also tried room/hotelRoom as an alternative. I also tried using the additionalType value to allow me to use product based options such as offers, but this didn't work.
JSON-LD:
{
"#context": "http://schema.org",
"#type": "Accommodation",
"additionalType": "Product",
"name": "example",
"offers": {
"#type": "Offer",
"name": "1 Night",
"priceSpecification": {
"#type": "PriceSpecification",
"price": 1,
"minPrice": 1,
"maxPrice": 2,
"priceCurrency": "GBP"
}
}
}
Google Structured Data Testing Tool:
The property offers is not recognized by Google for an object of type Accommodation.
How am I meant to add a price to a specific accommodation/room in my schema?
Schema.org intends¹ that authors use MTEs² in this case. That, however, does of course not necessarily mean that all consumers fully support this (yet).
So instead of:
"#type": "Accommodation",
you would use:
"#type": ["Accommodation", "Product"],
(additionalType": "Product", is not needed anymore, so could be removed)
While Google’s Structured Data Testing Tool only displays one type (seems to be always the first value in the array), it reports no errors when using this.
¹ The accommodation documentation does not yet reflect this (the changes are currently part of the draft for the next version), and the topic gets discussed here:
Remove Accommodation from all of the Offer-related schema and use MTEs instead
Hotel examples and documentation must be updated for MTE pattern
² MTE: Multi-Typed Entity.

What is the length of the 'description'/'name' properties for the 'Product' type in Schema.org?

I am playing with Schema.org, creating extensions for Google Rich Snippets based on JSON-LD, using https://schema.org/Product.
{
"#context": "http://schema.org/",
"#type": "Product",
"name": "Executive Anvil",
"image": "http://www.example.com/anvil_executive.jpg",
"description": "Sleeker than ACME's Classic Anvil, the Executive Anvil is perfect for the business traveler looking for something to drop from a height.",
"mpn": "925872",
"brand": {
"#type": "Thing",
"name": "ACME"
}
}
But I do not understand which how long the value for description and name can be. Seems to me that this is a very important value.
The vocabulary Schema.org doesn’t restrict the length that Text values can have. Not for Product nor for any other type.
Consumers (like Google Search) might have their own rules/restrictions. These should, hopefully, be described in their documentation. For Google’s Products rich result, no restrictions are specified for name/description.
Google indicates between >50 and <5000

RESTfully create or update a resource that references

If I wanted to create (POST) a new resource linking two independent resources, what is the most proper - with respect to HATEOAS and REST principles - way to structure the entity of the request?
Any references in RFCs, W3C documents, Fielding's thesis, etc., about the proper way for a client to request two independent resources be linked together would be most valuable. Or, if what I'm interested in is simply outside the scope of REST, HATEOAS, an explanation of why would also be great.
Hopefully my question above is clear. If not, here's a scenario and some background to ground the question.
Let's say I have two independent resources: /customer and /item, and a third resource /order intended to the two.
If I'm representing these resource to the client in a HATEOAS-like way (say with JSON-LD), a customer might (minimally) look like:
{
"#id": "http://api.example.com/customer/1"
}
and similarly an item like:
{
"#id": "http://api.example.com/item/1"
}
I'm more concerned about what scheme the entity of the POST request should have, rather than the URL I'm addressing the request to. Assuming I'm addressing the request to /order, would POSTing the following run afoul of HATEOAS and REST principles in any way?
{
"customer": {"#id": "http://api.example.com/customer/1"},
"item": {"#id": "http://api.example.com/item/1"}
}
To me, this seems intuitively OK. However, I can't find much or any discussion of the right way to link two independent resources with a POST. I discovered the LINK and UNLINK HTTP methods, but these seem inappropriate for a public API.
The client does not build URIs, so this is wrong unless these resource identifiers or at least their template came from the service. It is okay to use the id numbers instead of the URIs until you describe this in the response which contains the POST link.
An example from the hydra documentation:
{
"#context": "http://www.w3.org/ns/hydra/context.jsonld",
"#id": "http://api.example.com/doc/#comments",
"#type": "Link",
"title": "Comments",
"description": "A link to comments with an operation to create a new comment.",
"supportedOperation": [
{
"#type": "CreateResourceOperation",
"title": "Creates a new comment",
"method": "POST",
"expects": "http://api.example.com/doc/#Comment",
"returns": "http://api.example.com/doc/#Comment",
"possibleStatus": [
... Statuses that should be expected and handled properly ...
]
}
]
}
The "http://api.example.com/doc/#Comment" contains the property descriptions.
{
"#context": "http://www.w3.org/ns/hydra/context.jsonld",
"#id": "http://api.example.com/doc/#Comment",
"#type": "Class",
"title": "The name of the class",
"description": "A short description of the class.",
"supportedProperty": [
... Properties known to be supported by the class ...
{
"#type": "SupportedProperty",
"property": "#property", // The property
"required": true, // Is the property required in a request to be valid?
"readable": false, // Can the client retrieve the property's value?
"writeable": true // Can the client change the property's value?
}
]
}
A supported property can have an rdfs:range, which describes the value constraints. This is not yet (2015.10.22.) added to the hydra vocab as far as I can tell, but I don't have time to follow the project. I think you still can use the rdfs:range instead of waiting for a hydra range.
So in your case you could add an item property with a range of http://api.example.com/doc/#Item and so on. I assume you could add the links of the alternatives, something like http://api.example.com/items/, so you could generate a select input box. Be aware that this technology is not stable yet.
So you can send a simple JSON as POST body {item: {id:1}, customer: {id:1}} or something like that, which you generate based on the POST link. The RDF is for the client not for the server. The server can understand the data structure it requires, it does not need RDF. You don't need a dictionary to understand yourself...

Using the HAL vocab with JSON-LD

I was wondering, is there a way to use the HAL concepts with JSON-LD?
I have the current jsonld document:
{
"#context": {
"hal": "http://stateless.co/hal#",
"schema": "http://schema.org",
"_links": {
"#id": "hal:link",
"#container": "#index"
}
},
"#type": ["schema:Person", "hal:Resource"],
"name": "Jon Snow",
"_links": {
"self": {
"href": "/users/123"
}
}
}
but I am not sure how to define that the href has a #type of #id, and so on...
Is there a way to define a HAL vocab based on RDF(S) and import it somehow in the #context of my jsonld documents, or should I do something else?
(I am trying to describe hyperlinks with various properties, like link relation, HTTP method, accepted media type, language, IRI template, input fields, etc... so the #id type is not enough for me to describe links.)
As Tomasz already suggested, you should really consider using Hydra as it does more or less what you want. The example you've included in your questions, would look somewhat like this using Hydra and JSON-LD:
{
"#context": {
"schema": "http://schema.org",
"ex": "http://example.com/myvocab#"
},
"#id": "/users/123",
"#type": [ "schema:Person", "hydra:Resource" ],
"name": "Jon Snow",
"ex:link": { "#id": "/another-resource" }
}
As there's no need for a "self" link (#id already specifies that explicitly), I've added another link, ex:link. Its link relation is consequently http://example.com/myvocab#link and its "href" is /another-resource. If you need to describe that link/property in more details, you can do so by creating a document which defines it in exactly the same manner as other things are described (as Tomasz also already explained):
{
"#context": {
"ex": "http://example.com/myvocab#",
"hydra": "http://www.w3.org/ns/hydra#"
},
"#id": "ex:link",
"#type": "hydra:Link",
"hydra:title": "My new link relation",
"hydra:supportedOperation": [
{
"#type": "hydra:Operation",
"hydra:method": "POST",
"hydra:expects": ....
}
]
}
Regarding your comment
Btw. I am more or less familiar with the Hydra vocab, but I don't like
the idea to map the resources to real classes and objects on a server
side language and automatically transform the operation parameters
into those objects. Maybe it is possible to use the Hydra vocab in
another way, but I don't have the time to experiment with that.
Hydra is really just a vocabulary. It is up to you to decide how to use it. I think you are talking about the HydraBundle above. That's just one way to use it. It is just a proof of concept to show that it is easily possible. So please don't get confused by that.
I would like to invite you to join the Hydra W3C Community Group. We can then discuss this in more detail on our mailing list.
Disclaimer: I'm the creator of Hydra and the chair of the Hydra W3C Community Group.
I think you could be interested in Hydra. Have you tried that?
It's a vocabulary for describing Hypermedia links and operations. Here's how it could work for a simple parent link
{
"#context": {
"schema": "http://schema.org",
"parent": {
"#id": "/vocab#parent"
"#type": "#id"
}
},
"#id": "/users/123",
"#type": "schema:Person",
"name": "Jon Snow",
"parent": "/users/Ned_Stark"
}
Note that you don't need to include any data outside your domain in the representation. Instead you describe what the parent predicate means
{
"#context": "http://www.w3.org/ns/hydra/context.jsonld",
"#id": "/vocab#parent",
"#type": "hydra:Link"
}
You can also describe operations (HTTP methods, ranges, domains, etc.) and properties for classes. Also the operations can be included directly in the representation or attached to the classes and proeprties.