What is the correct itemprop for ImageObject?
On https://schema.org/ImageObject at the top there is caption for Image, but in the example they only show description.
I also found an example with itemprop="name".
All are valid properties to be used here.
Caption is specific to an ImageObject.
ImageObject inherits properties from Thing, which includes Description (and Name).
All are valid properties that can go on an ImageObject. I agree it's tough to tell the difference between Description and Caption in this case and the examples on schema.org could be better here.
As far as my interpretation of how it can be used, think of a picture of a couple on a beach:
Your Caption would be something such as "A couple enjoys their time on a beach in the Bahamas"
Description would be "A picture of a couple on a beach".
Name would be just a general title of the photo (or even the filename of the photo).
It's also worth noting that according to the Structured Data Testing Tool, neither Caption or Description are required, but both are accepted.
Related
While creating a new form,do we need to enter both title and name for the form?may i know why it is mandatory to enter both or what is the difference between Form title and name?
One more thing i noticed is like i can enter same title for multiple forms and is not unique.
The way it was explained to me, and how I have used them, is that the Title is the name of the form, how it is identified to yourself and others. The Name is the roll that it plays. So you might title the form MyDataForm1, but if the form is for the process of payroll analysis, it's name would be PayRollAnalysis1.
I hope I did not misunderstand the nature of the question, but that is how I interpret the answer.
Does anyone know how to create a link to the header of a different wiki page?
I know if I have a header ##Header name that I can link to it on that page by using (#header-name) as my link, but I want to link to that header from a different page. Is this possible?
ie. I want to have a table of contents that can link to the sub-sections of each wiki page as well as to the page itself.
Edit: I mean a way besides just using the url link
http://github.com/project/wiki/Wiki-Page#header-name
EDIT 1: So totally wrong about before, I just read up a bit more. So we have this new support as well inside of GitHub Wikis! (Relatively new.)
You can also do something like this:
[[ Link text | page_title#header_title ]]
This might work a lot better for you! TIL because of this answer here. You can see me do this with the Prerequisite link and you can see my other links work the other way. Time for me to do some updates!
EDIT 1: Still useful but definitely NOT THE ONLY WAY.
So I answered a question about this before, you should avoid absolute links on GitHub (i.e. https://github.com/user/repo_name/...)
However, a good way (and kind of the only way inside of Wikis EDIT 1: TOTALLY NOT TRUE TO BEING THE ONLY WAY) of doing what you need can be seen like this:
[Header link](/user/repository_name/wiki/page_name#title).
This is kind of the linking unfortunately that the Wiki would support. This will change your directory page based off of GitHub. You can see that it would be
https://github.com/(the linkage you want to hit)
I have actually began doing something like this in a Wiki I work on here. Inside of my Sidebar, you can see I have a Getting Started Page, and then a subsection into it is a Prerequisite heading and it will properly lead people to where they need to go. You would be able to perform this same thing on any page. It is a tad verbose, but worth it as you can easily change things around if need be. This is also case-sensitive since it will change their location so be sure that in your linkage, the page is the proper case and your heading is all lowercase.
Hope this helps!
You can link to the header by simply assigning an id to header. e.g you've "Extension" header in a page called Abc.
# <a id="extension"></a> Extensions
You have another page "Call center" and you want to go to extension in abc , you can use reference linking of markdown i.e "The [extensions][1] are handled by agents"
[1]: url-of-abc/#extension
I tested Maxwell's "good way" to link to the header of another page in Github in Edit 1 on and it works perfectly.
#[crux-ports Installation](/user/crux-ports/blob/master/README.md#installation)
markdown generate slug for the heading and convert it to id, example
# [ topic ][ color ]
will be converted to
<h1 id="topic--color" data-line="643" class="code-line">[ topic ][ color ]</h1>
Thus, to link it you can write it as [color](#topic--color).
If the destination anchor is on another page (assume filename css.md) with path relative to current markdown page, then you can write it as [color](css.md#topic--color)
Attach the slugify function from vscode
// excerpt from https://github.com/yzhang-gh/vscode-markdown/blob/908d7ba5465a203e4299f346c179211d992ef468/src/util/slugify.ts
const str = '# [ topic ][ color ]';
const slug = encodeURI(
str.trim()
.replace(/\s+/g, "-") // Replace whitespace with -
.replace(/[\]\[\!\'\#\$\%\&\'\(\)\*\+\,\.\/\:\;\<\=\>\?\#\\\^\_\{\|\}\~\`。，、；：？！…—·ˉ¨‘’“”々～‖∶＂＇｀｜〃〔〕〈〉《》「」『』．〖〗【】（）［］｛｝]/g, "") // Remove known punctuators
.replace(/^\-+/, "") // Remove leading -
.replace(/\-+$/, "") // Remove trailing -
);
console.log(slug) // "topic--color"
Using as a reference: https://support.google.com/webmasters/answer/146750?hl=en
You will notice under 'Product' that there is a category Property, and furthermore there's an example on down the page:
<span itemprop="category" content="Hardware > Tools > Anvils">Anvils</span>
which I've mimic'd exactly:
<span itemprop="category" content="kitchen sinks > stainless steel sinks > undermount">undermount</span>
Yet when I test it with Google's structured data tool, I get the error:
Error: Page contains property "category" which is not part of the schema.
I realized in the example also, it's using data-vocabulary.org→Product, where I'm using schema.org→Product.
Now on http://schema.org/Product, it does not have category anywhere mentioned. Does schema.org not offer categories? Or am I missing something?
category is an itemprop of schema/Offer, not schema/Product
To fix your problem, place an offer within the product, and attach the category to the offer.
Note: You are using a content attribute on span, which is not valid in HTML5 or Microdata (but in RDFa).
Schema.org has a category property, but it can not be used on Product. Depending on your content, you may want to use Offer instead of Product (see also my answer with an example use of category).
I've been working on JSON-ld & microdata a lot recently, and I believe in your case 'category' needs to be placed in a meta tag, not span/div tag, preferably before your item. Logically, your need to identify 'undermount' is redundant as it would already be included within your content. Oddly, the schema type service has 'serviceType' as a property, but product does not have an equivalent, otherwise that could have been another workaround. For your content 'undermount' use itemprop="name" within your span, no content within that tag necessary.
<meta itemprop="category" content="Hardware > Tools > Anvils > Anvils" />
Here is the correct format accepted by schema.org...
I'm probably biting off more than I can chew with this particular problem, but I'll try to be as specific as possible in case it's within my scope. Disclaimer: I'm not terribly experienced with MS Word, beyond simple data entry/some formatting, and I have absolutely zero experience working with macros or VBasic. Unfortunately, I'm afraid the solution to my problem will come in the form of one of those last two.
THE GOAL:
What I want to do is to have placeholder text throughout my template document that will change content but not formatting when the first instance of it is changed. Basically, I'm writing a template for support manuals for a software suite. Each app has certain similar features like the menu bar, data entry screen, diagnostic log screen, transaction history, etc., so I am pre-writing those sections and using placeholders when I need to insert certain app specific properties.
I started off using the Insert->Quick Parts->Document Property->Subject tool which I used as a placeholder for the app name. I set the Property to [Subject] and then used Insert->Quick Parts->Field->Subject throughout the document, wherever I needed to include the app name. This worked fine in this case because the app name will always be capitalized. I simply change the text in the first [Subject] (which is content controlled) and update the fields throughout the document, and they all match nicely, easy-peasy, work done, go home and drink beer, right?
Not quite.
Our software handles part tracking via scanners and SQL Server, so while the interface and menu in the apps remains largely unchanged, the parts they track change from app to app. Because of this, I need to change the part name when I reference it within the text of the manuals; for example, if I'm working in ToiletPap.app and our TP is tracked by the roll, I need every mention of [Component] to be changed to roll. If I'm working in LightBulbs.app, I need [Component] to say bulb.
My first efforts went toward creating a custom doc property called Component using the Advanced tab under the Document Properties dropmenu. I then created a plaintext content control around my first [Component] titled Component and made my next [Component] a field with modified code: {COMPONENT * MERGEFORMAT}. This comes from copying what I can find when [Subject] works. This didn't work at all; updating the text in the first CC doesn't change the Content doc prop, and my fields return "!Undefined Bookmark, COMPONENT".
I got close to what I need by using the [Comments] doc property, set initially to [Component]. I used it just like [Subject], but (this is when I realized that capitalization was going to be an issue) when I mention my [component] in-text, as often as not, I need to to be lowercase instead of upper.
I've looked on MS's forums and a few others as well as here on SO, and I can't find anyone who's trying to do the same thing, much less an answer to how. Please keep in mind when answering, it would be a great help to me if you would include step-by-step instructions on how to enter/implement the code you provide because, as I mentioned, I have no idea how to go about editing macros/VBasic for MS Word.
To restate and summarize my overall question: How can I use a placeholder that displays the text "[Component]" so that, when I change the first instance of [Component] to something else, say "hopper", every subsequent instance of [Component] is updated to hopper but maintains its current capitalization and formatting scheme?
Apologies for the length of the request, but I wanted to make sure I explained the situation as accurately as possible. Thanks in advance for your consideration and responses.
I managed to solve this one after a couple extra hours of tinkering. I didn't need macros or VBasic, either.
On the first instance of [component] I created a plain-text content control to act as a container (not a necessity, but it makes it look nicer. Will likely cause a problem eventually, but for now, it's working as intended) and bookmarked it. Then, for all other instances of [container] I selected each and used Insert->Quick Parts->Field->Ref with the following field code:
REF Text1 \*Lower
Where "Text1" is my bookmark and "*Lower" indicates all lower case. The *Lower can be replaced with *Upper or *FirstCap to indicate all upper case or capitalize the first letter respectively. Now, each field reflects the text of the first with the capitalization appropriate to each field's location within the document. Just like using the doc prop with [Subject], ^a -> f9 is needed to update all fields within the document.
I need to show in a page a list of, let's say, person's properties that should be rendered more or less as follow:
name: Name
date: 1/1/2000
other: Other
Reading the doc they say:
The LABEL element may be used to attach information to controls.
So, is it the right tag to encompass the names of the properties like name, date...
even if there's not an <input> to associate with?
Nope, as per Quentin’s answer.
However, in HTML5, <dl> can be used for generic associations where <label> isn’t appropriate.
No.
It says that it can associate information with controls.
It does not say that it can associate information with anything else.
See also the newer (but draft) specification:
Some elements, not all of them form-associated, are categorized as
labelable elements. These are elements that can be associated with a
label element.
button input (if the type attribute is not in the hidden state) keygen
meter output progress select textarea
No, it is not correct to use the label element like that.
The important thing here is the meaning of may.
The LABEL element may be used to attach information to controls.
RFC 2119 (which the HTML4 spec follows) defines may:
May: This word, or the adjective "OPTIONAL", mean that an item is truly optional
So here, may does not mean the label element can be used for other purposes; it just means that it is not required to use a label element with controls.
As far as alternatives go, it depends what you want to achieve. If you are just trying to follow the spec closely, then I suggest using p and a strong element for each pair. If you want the data to be more meaningful to computers, you could consider using one of the Microformat specifications.
I partially agree with the answers so far but want to add that if you want to use labels for some reason, then I would display the property values in read-only controls, and then your labels will be valid.
I've done this using appropriate styling to differentiate the read-only controls from the functioning controls to avoid confusing your users. This was on a sequence of pages which built up the information gathered from the user in a wizard.
I have this link to W3C - the "Editor's Draft" as opposed to the link above which is the "Working Draft", which states that you can associate it with any element - as long as it's 'labelable' - even though this is a subsection of the Form section. It states earlier that a labelable element does not have to be within a form.
http://dev.w3.org/html5/spec/single-page.html#the-label-element