I am reading up on Schema.org to be able to add the markup to a website I am working on. However, I'm already running into something I don't understand.
In the example for Product, it shows you should have a div whose itemprop is of type offers, but in the Product definition at http://schema.org/Product, I don't see offers as a property of Product at all.
If you look at http://schema.org/offers, it says offers is a property of Thing, but I don't see offers listed as a property of Thing at http://schema.org/Thing. What am I misunderstanding here?
Product does define the offers property. If you don’t see the offers property in the first table on that page (under the table heading "Properties from Product"), you are probably affected by a (known) bug. It typically works again when reloading the page later.
offers doesn’t have Thing as domain (but: AggregateOffer, CreativeWork, Event, MenuItem, Product, Service, Trip). If you are referring to the line "Thing > Property > offers", it doesn’t mean that the offers property is defined for/at Thing, it means that the offers property is a Thing. You can ignore that detail. What matters is the domain ("Used on these types") and the range ("Values expected to be one of these types") of a property.
It's perhaps worth highlighting the distinction between "types" and "properties". The vocabulary is a hierarchical taxonomy of the tangible and intangible things around us, which it calls types. In microdata, these use the itemtype attribute.
Properties describe the attributes of and relationships between the types, and in microdata use the itemprop attribute.
So, the type Product has the property offers (it's definitely there, you must be missing it1). A product can offer various things, one of which is the possibility of having some right to own or use it, which is described by the type Offer.
The property offers is indeed a property of Thing, but Thing is at the very top of the taxonomy, i.e. everything the ontology describes is a "thing", tangible or otherwise. So Thing is then broken down into more specific types of things:
Thing
- Intangible
-- Offer
-- Property
--- offers
So offers is a Thing like you and I are things — it's true, but we could be a lot more specific. In this case, offers is a property of the type Property, which in turn is a a more specific type of Intangible, which is a Thing.
1 Image of "offers" property under /Product:
Related
I'm currently using a multi-package open source framework that exposes dozens of classes/objects as type aliases in a root package, apparently solely for the purpose of making wildcard importing easy.
unfortunately, because these type aliases have the same name as the actual qualified type, they always come up first in the search function, which wastes time and valuable screen space.
is there an annotation I can put in front of a type alias to stop it from showing up in search? I don't want to omit it entirely from the documentation, because it obviously isn't irrelevant, it's just that nobody would look for these aliases by name. also note that I'm generating these docs for my own personal perusal, so we don't need to debate whether hiding members from search is bad practice for a public framework.
What is the difference between the Schema.org properties isPartOf and hasPart and when to use the one instead of the other?
As noted on their pages, they are inverse properties.
As an example, let’s take a webpage that is part of a website. You could then state one of these:
WebSite hasPart WebPage
WebPage isPartOf WebSite
It doesn’t matter which one you choose. (But there might of course be consumers that only recognize one of these properties.)
Note: Most of the time, Schema.org doesn’t define an inverse equivalent for a property. For example, there is author, but no authorOf. This is because you can use every property for both directions, with the help of the syntax:
RDFa:
rev
(example)
Microdata:
itemprop-reverse (non-standard, which is one of the reasons to prefer RDFa over Microdata)
(example)
JSON-LD:
#reverse
(example)
As there are a limited number of options available in Schema.org, I wonder whats the best schema to use when it doesn't fit into the other categories. For example if I'm writing about a Car (assuming there is no car schema as I've not seen one) then should I use the Article or WebPage schemas?
Official documentation suggests three options:
If you publish content of an unsupported type, you have three options:
Do nothing (don't mark up the content in any way). However, before you decide to do this, check to see if any of the types supported by schema.org - such as reviews, comments, images, or breadcrumbs - are relevant.
Use a less-specific markup type. For example, schema.org has no "Professor" type. However, if you have a directory of professors in your university department, you could use the "person" type to mark up the information for every professor in the directory.
If you are feeling ambitious, use the schema.org extension system to define a new type.
Also if you do not declare explicitly the type of a web page it is considered to be of http://schema.org/WebPage, that is the most general type that you can use in this case.
Quote source
(Schema.org has a type for cars, Car, which is a Product. I’m using a parrot as example in this answer.)
You might want to differentiate between the thing the page is about and the page.
You can mark up your page with WebPage, but that doesn’t convey what the page is about / what it contains. To denote that, you need another item that can be used as value for the about / mainEntity property.
If Schema.org doesn’t offer a specific type, go up in the type hierarchy. There’s always a type that works: Thing. Or in other words: start at Thing and go down until you find the most specific type. See my answer on Webmasters SE with more details.
So a page (WebPage) about a specific parrot (Thing) could be marked up like this:
<body typeof="schema:WebPage">
<article property="schema:mainEntity" typeof="schema:Thing">
</article>
</body>
And if possible, it can be a good idea to use suitable specific types from other vocabularies (e.g., from animal or even parrot ontologies) in addition to the Schema.org types. For example, you could use the Parrot type from DBpedia:
<body typeof="schema:WebPage" prefix="dbpedia: http://dbpedia.org/resource/">
<article property="schema:about" typeof="schema:Thing dbpedia:Parrot">
</article>
</body>
I have seen in a post that the slash is no longer up to date for creating new extensions in Schema.org.
I am using Microdata and would prefer to stick to it across my site.
What is the new way to create a new extension?
For example I want to create a new extension for MedicalTourism under the category Travel Agency. Before it would have been
http://schema.org/TravelAgency/MedicalTourism
What is the new way?
And what would the code look like?
You may still use Schema.org’s "slash-based" extension mechanism. It’s "outdated", but not invalid.
But it’s not (and never was) a good idea to use this mechanism if you want other consumers to understand or make special use of your extensions.
In some cases you could use Schema.org’s Role type, which allows you to give some additional data about a property, but not about types.
Alternatives
Propose new types/properties: If they are useful and the sponsors agree, they might get added to the Schema.org vocabulary at some point.
Use an existing vocabulary that defines types/properties for your use case (or create a new vocabulary if you don’t find one):
Either instead of Schema.org,
or in addition to Schema.org (while this works nicely with RDFa, Microdata is pretty limited: you’d have to use Schema.org’s additionalType property for additional types and full URIs for additional properties).
Often when I create new classes, I first create a new interface. I name the methods of my interface exactly as I would like them to behave. A colleague of mine prefers to have these method names being more abstract, ie: areConditionsMet(). The reason, he wants to hide the 'implementation details'.
IMO implementation details are different from the expected behavior. Could anyone perhaps give more insight. My goal is to reach a common ground with my colleague.
Your method names should describe what the method does, but not how it does it. The example you gave is a pretty poor method name, but it's better than isXGreatherThan1AndLessThan6(). Without knowing the details about what it should do, I would say that it should be specific to the problem at hand, but general enough that the implementation could change without affecting the name itself, i.e., you don't want the name of the method to be brittle. An example might be isTemperatureWithinRange() - that describes what I'm checking but doesn't describe how it's accomplished. The user of the method should be confident that the output will reflect whether the temperature is within a certain range -- whether this is supplied as an argument or defined by the contract of the class, is immaterial.
Interfaces should represent some behavior or capability and not the way it is to be accomplished. Users of interfaces should not be interested in the way a target is achieved, they just want to know its done.
Implementation issues should not be included within the name of methods for that exact reason. The name of the table updated as a result of this method or the technology used has nothing to do in your domain object's method's name.
However from your question it is hard to say what is the exact case at hand.
If you could provide more details perhaps i could provide an additional help.
The names of your interface methods should leave the user of the interface in no doubt about what the method proposes to do from a functional perspective. If the implementation matches that, well and good.
Based on your updated comments:
Sounds to me like you need two methods: isModified() and hasProperties(). Leave it up to the user (or higher layer) of the domain object to determine if a particular criteria is fulfilled.
An interface should also be designed with the view that after it is released it will never be changed. By saying isDomainObjectModifiedAndHasProperties() you are setting in concrete that this is the criteria of fullfilment (regardless of any future unforseen implementation).