-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Section B.3 of microdata has no example of original content reference #382
Comments
You are right: JSON-LD embedded in a data block requires some duplication of information, while Microdata avoids that redundancy. However, your JSON-LD snippet is not equivalent to the original example (nor to the corresponding Microdata, AFAICT). |
Hi @pchampin, I am supposing DOM, something like the Javascript's Is there any way to express it? It seems that you suggesting something more complex, something like [
{
"@id": "http://purl.oreilly.com/works/45U8QJGZSQKDH8N",
"@type": "http://purl.org/vocab/frbr/core#Work",
"http://purl.org/dc/elements/1.1/title": {
"@value": {"@id":"#tit01"},
"@type": "http://www.w3.org/2001/XMLSchema#string"
},
"http://purl.org/dc/elements/1.1/creator": "Wil Wheaton",
"http://purl.org/vocab/frbr/core#realization": [...]
}, ...
] ... But I also don't understand if in the |
It is not clear to me whether, in this issue, you are suggesting to improve section B.3 w.r.t. to the current state of the spec, or if you are suggesting to change the spec to support a better alignment with microdata... My answer above was assuming the first option (no change in the spec).
The two following JSON-LD snippets generate different RDF triples. That's what I meant by "not equivalent": "title": { "@id": "#tit01" } vs. "title": "Just a Geek" I am not denying that some pre- or post-processing could rebuild the 2nd one from the 1st one, but this is not standard JSON-LD processing.
No, that's not what I was suggesting, mainly because this is invalid JSON-LD (the value of |
JSON-LD is it's own representation, and is not designed to interoperate with either Microdata or RDFa, other than to produce RDF triples, which may be merged with each other. I don't see these specifications doing anything specific to pull data out of the DOM, although some other system could be constructed to treat some contents within a JSON-LD block as matching elements from the DOM through some dynamic programming. But, that's outside the bounds of the JSON-LD specifications themselves. |
Thanks @gkellogg, sorry for my wrong interpretation, I will close. Final questions:
|
You might check on other fora, such Stack Overflow for any prior art in using the DOM to supplement JSON-LD. Of course, one way to do it would be to parse all the JSON-LD and Microdata/RDFa out of a web page, merge into a single graph, and then serialize that back out as JSON-LD, which is in perfect keeping with all the various standards, but this does involve using Microdata and/or RDFa markup in addition to the JSON-LD. As long as the identifiers for the various entities align and can be reconciled (i.e., they're not blank nodes), this should work just fine. Of course, feel free to add issues suggesting features for a future version of JSON-LD. But, I don't believe that intermingling the different formats belongs in JSON-LD Syntax or API, but rather in some other document that depends on the component specifications. The JSON-LD CG would be the best place to foster such work, IMO. |
An important case is to express the semantics of the original HTML content (by JSON-LD). To be didactic, the example must to show that it is possible to cite (by intralink reference) the original content by its ID — avoiding to rewrite all HTML content into a set of separated JSON values. It is important, a good practice, to avoid redundant and unsafe content copies.
We can illustrate adding an ID in the Example 164, something as
So, Example 165 will be something as
Notes:
a typical JSON-LD will be embedded in the HTML, in a
<script type="application/ld+json">
block.the "Web Semantic interpreter" tool will accept this kind of relative intralink reference... The example is important because it shows that the tools must interpret intralinks (optionally doing internal text-content convertion).
The text was updated successfully, but these errors were encountered: