Comments (12)
Following discussion at TPAC, our proposal is to remove the JSON-LD conversion - it is just a convenience, and so long as you generate a minimal graph that is the same when converting to an RDF format it doesn't matter much which format you use...
And I apparently made fewer mistakes in creating the first draft RDFa conversion, so we will stick to that. It is also closer in the problem space it covers.
from microdata.
Ivan is correct, for the items
property to not create a blank node, the context must include "items": "@graph"
, or, the generation of the items
element should simply be eliminated, and replaced with "@graph"
, which is what I did in my implementation.
My implementation produces the following output for the example in the spec:
{
"@graph": [
{
"@context": {
"@vocab": "https://schema.org/"
},
"@type": [
"https://schema.org/BlogPosting"
],
"headline": [
"Progress report"
],
"url": [
{
"@id": "http://example.com?comments=0"
}
],
"comment": [
{
"@context": {
"@vocab": "https://schema.org/"
},
"@type": [
"https://schema.org/Comment"
],
"url": [
{
"@id": "http://example.com#c1"
}
],
"creator": [
{
"@context": {
"@vocab": "https://schema.org/"
},
"@type": [
"https://schema.org/Person"
],
"name": [
"Greg"
]
}
],
"dateCreated": [
"2013-08-29"
]
}
],
"datePublished": [
"2013-08-29"
]
}
]
}
from microdata.
It looks like the example was just copy-pasted from the plain JSON conversion, and is really wrong :(
So it looks like step 4 of the algorithm should say
Add an entry to result called "
@graph
" whose value is the array items.
@gkellogg you seem to have done the @context
step differently, and instead of making it a top-level entry in items added
@context : {
@vocab : _vocabulary-identifier_
}
to each item.
- Does that matter in getting the JSON-LD right? (I think at first glance the answer is no)
- Would doing the existing step 5, but with
@vocab
set to the vocabulary-identifier change the resulting graph? (Again, I think the answer is no)
Seem like we should also clarify that the algorithm is not normatively required to be followed exactly, but that a conversion should produce JSON-LD that represents the same RDF graph, probably at the beginning of the JSON-LD conversion section.
from microdata.
Setting @context
at the top means that if the vocabulary changes along the way, you won't pick it up. Setting it for each item, while repetitions, does make sure that the object for each item is picked up if it happens to change.
I believe that setting "@vocab": _vocabulary-identifier_
(when properly quoted) is don't what I do.
from microdata.
Setting @context at the top means that if the vocabulary changes along the way, you won't pick it up. Setting it for each item, while repetitions, does make sure that the object for each item is picked up if it happens to change.
But in microdata, my first instinct is that it cannot change anyway, in which case this protection is unnecessary. (Wondering if I missed something)
I believe that setting "@vocab": vocabulary-identifier (when properly quoted) is don't what I do.
vocabulary-identifier is (meant to be) the URL path for the (first) itemtype. Are you getting something different to use as a value? (I don't understand "don't" in the sentence above)
from microdata.
But in microdata, my first instinct is that it cannot change anyway, in which case this protection is unnecessary. (Wondering if I missed something)
In section 4.3, the vocabulary identifier is determined based on itemtype, which can certainly change when a new itemscope is encountered. Otherwise, you couldn't use properties from different vocabularies. Certainly, the RDFa algorithm is written expecting that the vocabulary identifier can change with each item, which is my read of 4.3 and 5.2:
The item types determine the vocabulary identifier.
I'm not sure where you see that the vocabulary-identifier is only associated with the first itemtype.
from microdata.
Looking at the example of @gkellogg's generation tells me that there is a need for a specific @context
file for microdata to make the output simpler and more readable. Lines like
"url": [
{
"@id": "http://example.com?comments=0"
}
],
could then disappear behind the smoke screen of a context. At present, without such a context file, the generated JSON-LD does not seem to be correct...
from microdata.
But in microdata, my first instinct is that it cannot change anyway, in which case this protection is unnecessary. (Wondering if I missed something)
In section 4.3, the vocabulary identifier is determined based on itemtype, which can certainly change when a new itemscope is encountered.
That is correct, but I believe the comment of @chaals referred to the @context
. While I agree that the vocabulary may change, I guess we can safely say that the @context
will not...
from microdata.
For the vocabulary to track, and properties to be properly expanded, the @context
must change with each item, at least for each item where the current vocabulary changes, otherwise, results will be quite different.
Consider a mixed use of DCMI and schema.org, if the context (and @vocab
) is set for one, then items that use an @itermtype
from the other will no longer come up as part of that vocabulary.
from microdata.
Ah, true.
Would it be an over-complication in the document if the algorithm includes a check on whether @context
and/or @vocab
is necessary (as far as I can see a simple check on the DOM tree would be sufficient)?
from microdata.
Simplest, of course, is to just emit an @context/@vocab
for each item, which doesn't require history. (Note that @vocab
can only be used within @context
). But, it might be done by passing current-vocabulary
into the algorithm, and editing the @context/@vocab
whenever the vocabulary identifier differs from that passed into the algorithm, and include it as part of step 7.2.
from microdata.
Exactly. I would propose to add that to the algorithm. Because we are generating a proper and, potentially, human readable serialization of RDF (as opposed to an abstract RDF Graph), I think such seemingly minor improvements would help acceptance and deployment.
from microdata.
Related Issues (20)
- Global Identifier
- Values section title odd
- Textual property value does not use language of the element HOT 4
- No description of how numeric property values are obtained. HOT 12
- Incomplete sentence: "User agents are"
- Syntax highlighting not working correctly HOT 12
- Capitalization of "microdata"
- give examples and algorithms a URL HOT 1
- Provide an example of itemid
- incomplete sentence "User agents are" HOT 2
- RDFa should generate to RDFa Lite HOT 4
- Use the same example for JSON-LD and RDFa HOT 6
- Reference to [microdata-rdf] should be changed HOT 13
- Reusing components in different contexts HOT 4
- itemref as a url, not just an ID within the same document
- "Valid" definition doesn't resolve
- "Our company" example is confusing
- Hedral the Cat HOT 1
- Hedral Issue 2 HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from microdata.