-
Notifications
You must be signed in to change notification settings - Fork 825
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
schema.org's JSON-LD context file should enumerate all terms #990
Comments
Correct. The contexts are evaluated in order. foo's |
So if we go ahead and implement #990 then we can tell publishers: "use pattern from example 1 if we want to overlay/overide foo's schemas on top of schema.org"; and to use example 2 pattern if they want to do the opposite and overlay schema.org on top of foo's schemas. The last named context in the array "gets the last word", which potentially affects two things: which vocabulary gets assigned any undeclared terms, and what to do if both contexts have declarations for the same term. From a schema.org perspective we might prefer "schema.org" to be last in the list, but other options could still be made to work if the situation called for it. In either case we can protect publishers from having to memorize which terms are at which URL and have some potential for transparently evolving things e.g. if terms migrate into the core or into an extension over time. /cc @vrandezo since Wikidata is one motivating usecase (#280), as is GS1's Web vocabulary (#258) at http://gs1.org/voc/ |
Exactly. The "which vocabulary gets assigned any undeclared terms" only applies if both context's use I agree that having schema.org last is probably better in most cases. |
I've just been looking into this and using the JSON-LD playground tool to check the resulting triples. The JSON-LD playground report an error when attempting to use an array of values as you suggest, e.g. "@vocab": ["http://gs1.org/voc/","http://schema.org/"] - it says that the value of @vocab in @context must be a string or null. Looking at section 8.7 of the JSON-LD spec it says: Since Markus @lanthaler is one of the co-authors of the JSON-LD spec, I'm sure he can provide clarification on this point and advise whether the JSON-LD playground and other validation tools should be updated to accept arrays of IRIs for the value of @vocab. |
I believe (@lanthaler can correct!) that while @context can take an array, whereas there is only one @vocab current at any place in the JSON tree. |
Hi @danbri, Looking at the actual examples of @context in https://www.w3.org/TR/json-ld/#context-definitions I don't see any examples where @context is taking an array in the way you suggested above. @context expects an object (in curly brackets, not square brackets) and within that, it's the @vocab term that indicates what the default vocabulary is - the vocabularies cannot just be stated without an @vocab key. Even if we were using multiple @context blocks within an array, as in https://www.w3.org/TR/json-ld/#advanced-context-usage , the spec says that the most recently defined term wins. So, if we can only have one @vocab per @context and it can only take a single IRI value, then even if we later specify an additional @context with one @vocab with a different IRI value, its value will win and the previous value of @vocab will be ignored. Or am I missing something? If Markus @lanthaler or anyone else can provide a correct JSON-LD snippet that validates correctly in the JSON-LD playground tool and also allows us to indicate a prioritised list of default vocabularies as @danbri intended, that would be really helpful. |
It is not
Assuming that GS1's context is being served from
Right. That's why it is important to explicitly define each term instead of relying on |
Hi Markus @lanthaler Thanks for joining the discussion. However, after fixing the typo (missing double-quote after "@context ), I can get this to validate in the JSON-LD playground: { but not this: { This does not validate. If I've misunderstood what you meant, please could you correct / expand the example and also check that it validates at http://json-ld.org/playground/ ? In the JSON-LD markup examples for the GS1 vocabulary we are explicitly defining each term - especially for every owl:ObjectProperty , anything expecting an rdf:langString, anything expecting a URI or an xsd datatype. The downside is that we have a fairly large @context block for the whole vocabulary. |
{ ... this works (even if it does not make much sense). I think your "does not validate" must refer to an error in fetching a real context file from the URL. Are you seeing "jsonld.InvalidUrl - Dereferencing a URL did not result in a valid JSON-LD object..." or some different error? |
Thanks - it looks like I previously misunderstood that the notation above was actually retrieving remote contexts - and we don't currently have a remote context file on the gs1.org site. I have now got the following snippets validating correctly: { or { In the first snippet, the draft GS1 @context is called last, so it overrides the schema.org definition of 'productName', resulting in the triple: _:b0 http://gs1.org/voc/productName "Nexus 7" . In the second snippet, the schema.org context is called last, so it overrides the GS1 definition of 'productName', resulting in _:b0 http://schema.org/productName "Nexus 7" . Obviously there is still a problem with http://schema.org/productName - that property is not defined. We have tried to align with many schema.org terms where they are an exact semantic match (e.g. unitCode, Product, Offer, etc.) - but we avoided overloading terms such as 'name' and 'description', preferring instead to define distinct terms for productDescription, offerDescription etc. So it looks as though we'll still need to define two context files for the GS1 web vocabulary - one purely for GS1 terms and a mixed context file that maps 'productName' explicitly to 'schema:name' etc. for those terms where there is a mapping. |
For fooName, fooDescription, barName, barDescription etc, would it make sense to declare them (in RDFS rather than JSON-LD context mechanism) as sub-properties? |
In the GS1 vocabulary itself, we define the following RDFS mappings to schema.org gs1:afterHoursContact rdfs:subPropertyOf schema:contactPoint . We also define the following subclass relationships relevant to schema.org: gs1:Beverage rdfs:subClassOf gs1:FoodBeverageTobaccoProduct . However, our RDFS statements are currently missing: gs1:Offer rdfs:subClassOf schema:Offer because so far we've only stated a skos:exactMatch relationship for these. http://example.org/abc rdf:type gs1:FruitsVegetables and any schema.org validation tools would understand that because then http://example.org/abc rdf:type schema:Product For other properties such as gs1:width , gs1:depth and gs1:height , the mapping to schema.org terms is more complicated because the rdfs:domain (or sometimes the rdfs:range) of these is different - |
@mgh128 that only happens because http://milecastle.media/pureGS1context.jsonld doesn't define |
Perhaps it is best in the GS1 Vocabulary that we remove the Dimensions class and create gs1:inPackageWidth, gs1:outOfPackageWidth etc . Best not to have a gs1:width and schema:width with different meanings. |
Thinking out loud: I was assuming that we need only define properties exhaustively, because that's the only piece of JSON-LD syntax that can be ambiguous. But now I'm thinking it must be all terms because otherwise Person etc might end up in the wrong namespace too. |
We're in the process of overhauling our JSON-LD markup tool for GS1 SmartSearch so that all datatype coercion (for anything other than xsd:string) and all @language tagging is done within the main body of the JSON-LD block, next to the value, in order to keep the @context file fairly minimal and make it more scalable, since many of our properties have an rdf:langString as their range and there are countries (e.g. Canada, Belgium, Switzerland) with multiple official languages and therefore multi-lingual values for various product details such as lists of ingredients etc. In the GS1 SmartSearch vocabulary, we have mostly tried to align with schema.org nomenclature except that we have not overloaded properties such as 'name', 'description' but instead define separate specific properties such as gs1:productDescription, gs1:offerDescription etc., although the mappings to schema.org equivalent properties are indicated in the GS1 SmartSearch vocabulary at http://gs1.org/voc , where we define mostly rdfs:subPropertyOf, rdfs:subClassOf relationships to related terms in schema.org We have been discussing with you the capability to use schema.org terms in combination with terms from GS1 SmartSearch vocabulary for more specific details not currently covered in schema.org. I think you're noting that we have some subclasses of schema:Product such as gs1:WearableProduct, gs1:Footwear, gs1:Clothing, gs1:FoodBeverageTobaccoProduct, gs1:Seafood etc. As far as I recall, apart from schema:Product the only other subclass we define is a gs1:ReferencedFileDetails as a subclass of schema:MediaObject If it helps, I can provide a markup example of mixed vocabulary use (schema.org + GS1 SmartSearch) and the extended @context block and show how this compares against a markup example for only GS1 SmartSearch vocabulary use. |
That's right. You would also need to explicitly define classes etc. so that they aren't moved to a different namespace by another context's |
…taTypes, from core and all extensions. Addresses issue (#990)
I've merged @RichardWallis 's work, here's a staged version to review: |
The context looks good to me. |
Fixed in V3.0 |
In the current situation where we list only @id-typed and datatyped (e.g. DateTime) properties, other terms such as literal-valued properties, types, enumerated values are not explicitly "claimed" by schema.org. In the case of e.g. 2 above, that is OK. In the case of e.g. 1 above, a declaration of @vocab within foo.example.org's JSON-LD context file will "claim" all the non-explicit schema.org terms, so that Person will expand to http://foo.example.org/Person instead of http://schema.org/Person etc.
By making schema.org's context list everything, we allow instance data and external context authors to choose how to mix and superimpose it with other vocabulary.
<- this is my understanding of the situation at least, but am open to corrections. --@danbri
The text was updated successfully, but these errors were encountered: