Structured Data > Microdata & Json-LD > Entity IDs > Fragment Identifier

Question

I was wondering if it is better/proper to reference the entities using a fragment identifier format - basically by inserting a hash before the name

[url] + # + [name] => http://example.com/page/#webPage

EDIT:

Following a kind answer from the ever-generous and great @Unor, I have added this edit to try confine the scope of my query and clarify the main issue I am getting at. I have also deleted most of the original question (about 95%) which (in hindsight) I feel detracts from: 1. my core question; and 2. the benefit to future readers.

Here is my issue in short:

Is the practice of manually typing in a hash at the start of microdata's itemid and json-ld's @id values valid?

Here is my issue expressed in more detail:

Can I insert a HASH symbol (#) into microdata's itemid values and json-ld's @id values, to create valid resulting URIs with a proper and valid use of a fragment identifier?

So if this is on a web page:

<div itemscope itemtype="http://www.schema.org/Person" itemid="#joe"></div>

Or if this is also on the web page:

{"@context":"http://schema.org",
"@type":"Person",
"@id":"#Joe"}

I understand they will be read to make a uri like this (assuming relative construction by the consumer as Google's structured data tester tool does):

http://www.example.com/page#joe

Is that uri:

1. a valid uri; and

2. is it properly using a fragment identifier (HASH)?

Answer 1

It’s a good practice to allow to retrieve a description about the entity when requesting the URI (see Cool URIs for the Semantic Web: 1. Be on the Web.).

By using Hash URIs, you get this functionality for free:

• http://example.com/flower represents the document about a flower
• http://example.com/flower#this represents the flower
• → When retrieving http://example.com/flower#this, you get the document about it

By using Slash URIs, you have to implement a redirect (with status code 303) yourself:

• http://example.com/flower represents the document about a flower
• http://example.com/flower/this represents the flower
• → When retrieving http://example.com/flower/this, you get 303-redirected to the URI about it (see an example)

So without knowing more about your backend, I’d suggest to go with Hash URIs, because it is typically easier to set up.

(I’m not sure what exactly you mean with "webpage entity", but just to make sure: the Hash URI should be for the "real-world object", not for the document.)

---

Edit (for your updated question):

Yes, you can provide the Hash URI in itemid and @id (example) by specifying only the fragment component (starting with a #).

So on a document with the URL http://example.com/foobar, these four statements generate the same Hash URI (http://example.com/foobar#this):

<article itemscope itemtype="http://voc.example.net/Example" itemid="#this">
</article>

<article itemscope itemtype="http://voc.example.net/Example" itemid="http://example.com/foobar#this">
</article>

<script type="application/ld+json">
{
  "@context": "http://voc.example.net/",
  "@type": "Example",
  "@id": "#this" 
}
</script>

<script type="application/ld+json">
{
  "@context": "http://voc.example.net/",
  "@type": "Example",
  "@id": "http://example.com/foobar#this" 
}
</script>

(And yes, your example URI is valid; here’s which characters the fragment component may contain.)

Notes:

• The fragment is case-sensitive, so your itemid="#joe" and "@id":"#Joe" resolve to different URIs (j vs. J).
• When not specifying an absolute Hash URI, you have to make sure that the URL of the current document is canonical. For example, the trailing slash matters (/page/#joe vs. /page#joe); the query component matters (the page /page?foo=bar would create the Hash URI /page?foo=bar#joe, not /page#joe); if the host has www. or not matters; the URI scheme matters (http vs. https); etc.