This may sound like a stupid question, but: which language should I use for my code markup? I'm writing articles in German language.
Of course the tags themselves are fixed, but how to help bots understand the topic I'm writing about?
<div itemscope itemtype="http://schema.org/MedicalWebPage">
<link itemprop="about" href="http://schema.org/MedicalCondition" />
<meta itemprop="name" content="Posttraumatische Belastungsstörung"/>
<meta itemprop="aspect" content="Psychotherapie"/>
<meta itemprop="keywords" content="Trauma, PITT, PTBS, PTSD, Traumatherapie"/>
<meta itemprop="alternateName" content="PTBS"/>
The following questions arise:
Can I add a few 'aspects' within a single property or do I have to
add 1 'aspect' tag for each?
would it be better to use the English terms for categorizing properties such as 'aspect' or 'keywords', like using
'psychotherapy' or 'diagnosis' instead of 'Psychotherapie' and
'Diagnose'?
of course I'd like to avoid bloating my html code. Does it even make sense to define another 'keywords' tag if I have the respective
regular meta tag in my document anyway?
The obvious way is to use the language the content/document is in. This becomes clear if you think of, for example, a BlogPosting: its name should of course be the actual blog posting title, not a translation of it; even more so the articleBody. In general, this is the case for properties like aspect and keywords, too. However, in some cases Schema.org might decide to recommend to use certain values (so not just giving examples, like they do for aspect)¹, in which case you should follow this advice instead of translating the values.
Having said that, there could of course be consumers that do something with German content but expect certain properties with certain values (in a certain other language) for that purpose. Unless you know about such a consumer, I wouldn’t worry about it.
You could provide values in multiple languages if you think it’s useful. In Microdata, parsers wouldn’t differentiate between the languages (as Microdata doesn’t care about HTML’s lang attribute, so it’s not very practical), but it’s possible with RDFa.
¹ In such a case, they should ideally use enumeration URIs, as they are language-independent; e.g., for MedicalSpecialty: http://schema.org/Psychiatric, http://schema.org/PlasticSurgery etc.
Related
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).
I'm trying to design a RESTful interface for a filesystem-like web service. To provide hyperlinkability among the various resources (files, directories, etc.), I thought I would use XLink. However, it seems there is a strange omission from XLink: content types.
Atom provides an attribute to specify the content type of links as well as the linked resource's relationship to the current, as in:
<link rel="alternate" type="text/html" href="http://example.org"/>
Because I am creating a custom content type for each of my resources' representations, this seems like an important bit of information to include in my hyperlinks.
I can kind of make out an analog to rel in the XLink spec (label, from and to, I guess?), but why is content type missing from XLink? Do they intend that the role is somehow meant to convey what a client finds at the end of a link? Perhaps I missed the purpose of XLink?
It appears xlink has purposely ignored this; the only mention of media types or representations has to do with how fragment identifiers are to be interpreted. XLink actually only defines links to be between resources, and not their representations.
This means that if you used XLink you have to define your own way of specifying the expected media type of the target of the link, whereas if you use Atom's link you get the target media type, but not the versatility of XLink.
Since you're probably defining your own media type, it's not extremely important unless you want generic clients that don't know of your media type to be able to parse the embeded links. Any client that knows about your media type can read your documentation, and will know to use XLink, Atom, HTML (the link element) or your own proprietary link semantics.
Just as an example of the latter: The Sun Cloud API uses a JSON list of objects with rel, and href attributes for outgoing links.
what it better practices for creating web forms, using tables or lists ?
Regards
Javi
Neither.
A form is just a form. It might consist of paragraphs, simple blocks (divs), or something else.
Sometimes that forms are tabular or lists, but not often.
There is no such a rule :-) You should use tables for tabular content, you shouldn't use it for you page layout since it's a bad html practice.
You'll find a lot about it on google. Tables vs DIV
It depends on your context. If we're speaking about web forms with labels and input fields, then having a structure using divs is most comfortable for a concept of composition
<div>
<label... for="..">
<input type="text"...>
</div>
<subcontrol...>
<div>
<label... for="..">
<input type="text"...>
</div>
This is then properly formatted by using CSS s.t. the things are well aligned in the form
Label: input field
Label2: input field
Composition therefore because as you see in the "HTML" above "subcontrol" may be an arbitrary reference to a control containing again the same div structure and the finally produced page would just look nicely.
The same may apply to tables, but the concept of composition already gets messier since you get nested tables as the result. Moreover some screenreaders often have problems with those nested tables (as many argue, have never tried it though).
Conclusion: It really depends on how you're accustomed to it. Personally I prefer divs and CSS because you can control it better once you have defined your overall layout.