JSON-LD context problem for properties that can take both URL or Text about schemaorg HOT 41 CLOSED

Regarding the last paragraph in your comment: Can the schema.org JSON-LD context be used and overwritten in such situations?

Yes, use a JSON-LD document such as the following:

{
  "@context": ["http://schema.org", {
    "url": {"@type": "@id"}
  }],
  url: "http://some-location/"
}

This will ensure that the url property is treated like an IRI, not a literal. This may be the default in the schema.org context, but it definitely isn't for other properties you probably want to have interpreted as IRIs. You can also put these in an external document, and either access as "@context": ["http://schema.org", "http://myschemaupdates"], or simply make myschemaupdates also include http://schema.org.

from schemaorg.

This remains an issue for multiple properties that permit both literals and URIs, including schema:genre (as just raised in openlink/structured-data-sniffer#13).

On 2014-06-19, @danbri said about schema:Role —

Just discussed this with the schema.org team, we agreed that in this case defaulting to text makes sense. I'll get the context file updated accordingly.

— and indeed that now shows —

"Role": {"@id": "schema:Role"},

— but schema:genre and others are the troublesome —

"genre": { "@id": "schema:genre", "@type": "@id"},

I submit that the ranges of all such properties should be limited to URIs, or the context file should be adjusted to do the right thing with the beginner-user's most likely initially-textual value, and leave the more-experienced-user to handle the need for the more complex formulation of —

"genre": { "@id": "http://example.com/genre#myfavorite" },

from schemaorg.

This is a known family of headaches, but I do not see an actionable issue identified here any more. Let's close this, but remember this as a useful discussion that will surely crop up again.

from schemaorg.

http://schema.org/Text looks very not helpful suggesting that one can use Text on all properties 👎

also DataType > Text > URL in a way makes sense but also doesn't look helpful in this case

from schemaorg.

If we include a reference to this context, both the json-ld playground and the rdf translator assumed the string "felt-tip pen" to be a fragment IRI, not a literal. However, the Google Structured Data Testing Tool, looks to be treating "felt-tip pen" as a literal. Apparent inconsistency.

Out of spec, but the SDTT is trying to be clever and figuring that the embedded space makes the intent clear. Via Postal's rule, it's reasonable for a consumer to be liberal in what it accepts, but the SDTT should probably note this as being inconsistent with the term definition. To be strict, it should be interpreted as an IRI, but the IRI would be invalid due to the unescaped space character.

Error message from Structured Data Testing Tool (last line in red):

  artMedium    
               is not a known valid target type for the artMedium property.

This would seem to be a bug in the SDTT, as the vocabulary clearly says that schema:Text is in the range (which includes string and language-tagged RDF literals).

The SDTT is clearly capable of dealing with literal values, so it's not clear what's going on here, but IMHO, the problem is with SDTT, not the vocabulary definition. As I said earlier, the context should not use @type: @id when schema:Text is in the range.

from schemaorg.

https://schema.org/docs/jsonldcontext.json
has 72 properties defined as "@type": "@id"

https://github.com/schemaorg/schemaorg/blob/1b4f918e2253c3568cced0a831a64c098f05aad8/data/schema.rdfa
defines

• 861 properties
• 302 properties with rangeIncludes schema:Text
• 64 properties with rangeIncludes schema:URL
• 33 properties with rangeIndludes schema:URL & schema:Text

As I said earlier, the context should not use @type: @id when schema:Text is in the range.

30 properties have "@type": "@id" definition in the context and at the same time rangeIncludes schema:Text (list: https://gist.github.com/elf-pavlik/c8d02ee77410db2fd9f819703f031140#file-under-question-js )

so as in example from previous comment "artMedium": "felt-tip pen", values of those 30 properties interpreted as URI if they don't use "@value": but plain string

at the same time out of all 861 properties only 302 have rangeIncludes schema:Text so plain sting values of remaining 559 - (72 - 30) = 517 which don't have rangeIncludes schema:Text and don't have "@type": "@id" will get interpreted as literals not as URI

I think in this situation, it seems safest to always stay explicit and always use

• { "@id": "https://foo.example/" }
• { "@value": "bar" }

and don't rely on schema.org JSON-LD context having or not having "@type": "@id"

from schemaorg.

Do you have your 'modified' context published somewhere?

from schemaorg.

I'm afraid not.
My initial approach was to remove the (, "@type": "@id") for the properties defined as both URI or some other type.
Specifically these (as mentioned in the linked issue):
"roleName": { "@id": "schema:roleName", "@type": "@id"},
"acceptsReservations": { "@id": "schema:acceptsReservations", "@type": "@id"},
I could find no easy way of automating this process to be able to discriminate between pure URI types and the hybrids. In the end for the application I needed, I could just populate with an empty(ish) context file and have not suffered any consequences in my particular application. Mileage may vary for other use cases.

from schemaorg.

This is not only a problem for JSON-LD. It also leads to problems with OWL.

from schemaorg.

When I generate my own JSON-LD context for schema.org I do not set @type to @id for properties where the range includes schema:text (or similar literal value). IMO, it's more intuitive for an author to use {"@id": "/foo"} than {"@value": "foo"}.

Of course, any object-ranged property can take a plain text value, but in that case it makes sense to require the explicit @value method; perhaps the documentation should reflect this.

from schemaorg.

Just discussed this with the schema.org team, we agreed that in this case defaulting to text makes sense. I'll get the context file updated accordingly. There are a few corner cases to document, I'll sketch something in the wiki here for sanity checking before putting it to a wider audience.

from schemaorg.

FWIW I've just run into something close to this again, but for enumerations.

e.g. this proposed addition to Map,

{
"@context": "http://schema.org/",
"@type": "Museum",
"name": "SF art museum",
"hasMap": {
"@type": "Map",
"mapType": { "@id": "http://schema.org/VenueMap" },
"url": "http://art-sf.example.com/map1234/"
}
}

... not clear whether enumerated properties should try to force a URI interpretation, or better to use @id in all cases for clarity. I lean towards the latter.

from schemaorg.

Are there rules you can derive from the RDFs that tell you when to use @type @id? At the extreme end, if any object-valued property may take plain text! then you won't use it at all! which will lead to the opposite problems.

You could consider adding schema:Text to the range of any property that should not up have @type: @id, since this is allowed by the data model anyway, and at least then there would be product able rules.

from schemaorg.

I see need for clear documentation about properties which allow Text
To my understanding person just needs to remember to for URI values always use {"@id": "/foo"}
@gkellogg any comments on how parsers tell difference in Microdata and RDFa ?

from schemaorg.

Microdata and RDFa depend on the use of an appropriate attribute, such as @href or @resource to know if it's an id.

Schema:URL certainly suggests that there are some properties which should never take a literal. How should the vocabulary describe this if not by adding schema:Text where it is appropriate?

from schemaorg.

@danbri maybe blank nodes could help here?

{
  "@context": "http://schema.org",
  "@type": "SportsTeam",
  "name": "San Francisco 49ers",
  "member": {
    "@type": "OrganizationRole",
    "member": {
      "@type": "Person",
      "name": "Joe Montana"
    },
    "startDate": "1979",
    "endDate": "1992",
    "namedPosition": {
      "name": "Quarterback"
    }
  }
}

this way namedPosition doesn't need to include Text in its range...

from schemaorg.

I think schema.org may need {"@type": "@id"} for many more properties. For example, I wrote this example of Action: http://tiny.cc/ob4oox

{
  "@context": "http://schema.org",
  "@type": [
    "DislikeAction",
    "CommentAction"
  ],
  "@id": "https://wwelves.org/perpetual-tripper/2b6d04ab-f8f9-429c-a526-547b15c617f7",
  "agent": "https://wwelves.org/perpetual-tripper",
  "object": "http://tmblr.co/ZxcvMv1UViUDg",
  "result": {
    "@type": "Comment",
    "@id": "https://wwelves.org/perpetual-tripper/61f671f7-5fb5-452a-bccf-153ac5c31b1a",
    "sameAs": "http://tiny.cc/ob4oox",
    "about": "http://tmblr.co/ZxcvMv1UViUDg",
    "author": "https://wwelves.org/perpetual-tripper",
    "text": "most web APIs nowadays use JSON, with JSON-LD we can simply describe them in machine readable way",
    "seeAlso": [
      "http://manu.sporny.org/2013/json-ld-is-the-bees-knees/",
      "http://www.slideshare.net/lanthaler/stop-reinventing-the-wheel-use-linked-data-to-build-better-ap-is/26",
      "http://youtu.be/KB94dIamAQc"
    ],
    "potentialAction": [
      { "@type": "ReactAction" },
      { "@type": "CommentAction" }
    ]
  }
}

expanded JSON-LD has { "@value": "..." } where most people IMO expect "@id"

[
  {
    "@id": "https://wwelves.org/perpetual-tripper/2b6d04ab-f8f9-429c-a526-547b15c617f7",
    "@type": [
      "http://schema.org/DislikeAction",
      "http://schema.org/CommentAction"
    ],
    "http://schema.org/agent": [
      {
        "@value": "https://wwelves.org/perpetual-tripper"
      }
    ],
    "http://schema.org/object": [
      {
        "@value": "http://tmblr.co/ZxcvMv1UViUDg"
      }
    ],
    "http://schema.org/result": [
      {
        "@id": "https://wwelves.org/perpetual-tripper/61f671f7-5fb5-452a-bccf-153ac5c31b1a",
        "@type": [
          "http://schema.org/Comment"
        ],
        "http://schema.org/about": [
          {
            "@value": "http://tmblr.co/ZxcvMv1UViUDg"
          }
        ],
        "http://schema.org/author": [
          {
            "@value": "https://wwelves.org/perpetual-tripper"
          }
        ],
        "http://schema.org/potentialAction": [
          {
            "@type": [
              "http://schema.org/ReactAction"
            ]
          },
          {
            "@type": [
              "http://schema.org/CommentAction"
            ]
          }
        ],
        "http://schema.org/sameAs": [
          {
            "@id": "http://tiny.cc/ob4oox"
          }
        ],
        "http://schema.org/seeAlso": [
          {
            "@value": "http://manu.sporny.org/2013/json-ld-is-the-bees-knees/"
          },
          {
            "@value": "http://www.slideshare.net/lanthaler/stop-reinventing-the-wheel-use-linked-data-to-build-better-ap-is/26"
          },
          {
            "@value": "http://youtu.be/KB94dIamAQc"
          }
        ],
        "http://schema.org/text": [
          {
            "@value": "most web APIs nowadays use JSON, with JSON-LD we can simply describe them in machine readable way"
          }
        ]
      }
    ]
  }
]

from schemaorg.

Not sure where we stand with this, maybe it was even fixed? Does anyone believe there is an outstanding problem?

For info the homepage content-negotiable JSON-LD context is also accessible here: http://schema.org/docs/jsonldcontext.json.txt

from schemaorg.

Also see comment in #197: This tool generates a context based on schema:rangeIncludes.

from schemaorg.

Not sure if we have an action here.

from schemaorg.

I think this is still an issue, in particular in the context of http://schema.org/Car

from schemaorg.

Example:

Example:

{
"@context": "http://schema.org/",
"@type": ["Car", "ProductModel"],
"cargoVolume": {
"@type": "QuantitativeValue",
"unitCode": "LTR",
"value": "500"
}
}

is parsed by

http://json-ld.org/playground/

as

[
{
"@type": [
"http://schema.org/Car",
"http://schema.org/ProductModel"
],
"http://schema.org/cargoVolume": [
{
"@type": [
"http://schema.org/QuantitativeValue"
],
"http://schema.org/unitCode": [
{
"@id": "http://json-ld.org/playground/LTR"
}
],
"http://schema.org/value": [
{
"@value": "500"
}
]
}
]
}
]

Note the

    "http://schema.org/unitCode": [
      {
        "@id": "http://json-ld.org/playground/LTR"
      }
    ],

where is should be

    "http://schema.org/unitCode": [
      {
        "@value": "LTR"
      }
    ],

from schemaorg.

Looking at this again, how special is unitCode? Are there any other properties that have rangeIncludes URL but which we would want to default to @value values?

http://schema.org/docs/jsonldcontext.json

cat data/releases/3.1/all-layers.nt | grep rangeIncludes | grep URL > takesurls.txt

from schemaorg.

Since this issue is still open, I'm adding additional illustrations and responding belatedly to @danbri question in August about other properties that have rangeIncludes URL but which we might want to default to @value values. For properties that are Text as often or more often than they are URL, the way it currently is creates the issues discussed below and elsewhere on this page. Bottom-line: We have 5 more properties to add to the list, though for reasons discussed below we actually would prefer that the definitions for these properties simply be left untyped in the schema.org context document.

artworkSurface
artMedium
artform
genre
fileFormat

Documentation says that these properties all allow both Text and URL values, but the default context document specifies only the latter (i.e., "@type": "@id"). Of these 5, I suspect fileFormat and perhaps genre may be the most ubiquitous and problematic generally.

@gkellogg and others have noted that there are work-around options, but we've noted that various tools make different assumptions and have different levels of tolerance for these workarounds, as illustrated below. For our use cases, for the tools we are focused on, we found that the best option was to redefine in our graphs the properties of interest to have no type (which is the way schema.org properties that can only have Text values, e.g., name, are defined in the context document). Having done this, when we can / need to supply a URI value, we do so using objects having an @id property (we can but do not include an @type property on these objects, though we don't know yet if this decision has implications for some tools).

Our criteria for success - we want our graphs to be translated as expected by the RDF Translator [1], work as expected in the JSON-LD Playground [2], and pass validation by the Google Structured Data Testing Tool [3], preferably with no warnings (but we have concluded provisionally that "Unspecified Types" were okay in that tool - not sure the practical implications of this decision).

Currently, the context document that is retrieved from http://schema.org uses definitions for all of the above properties that specify: "@type": "@id", but we often need to be able to provide Text values for these properties. For example, most extent illustrations of fileFormat (all on the schema.org definition page) feature text strings, e.g., "image/png", but the schema.org definition also allows URLs, e.g., for a Wikipedia entry for an as yet unregistered mime types, or perhaps even for some registered types, e.g., https://www.iana.org/assignments/media-types/image/jp2.

Here's a stripped down version of our starting point -- note, the http://vocab.getty... is the URI assigned to the concept "pencil (marking material)":
{
"@context": "http://schema.org",
"@type": "VisualArtwork",
"artMedium": [
"felt-tip pen",
"http://vocab.getty.edu/aat/300410335"
],
"associatedMedia": [
{
"@type": "ImageObject",
"contentUrl": "http://example.org/myPic.jpg",
"fileFormat": "image/jpeg"
},
{
"@type": "ImageObject",
"contentUrl": "http://example.org/myPic.jp2",
"fileFormat": "https://www.iana.org/assignments/media-types/image/jp2"
}
]
}

The Structured Data Testing Tool is happy with this, but JSON-LD Playground and the RDF Translator attempt to turn the strings "image/jpeg" and "felt-tip pen" into URIs, which is not at all what is wanted.

The next version works fine in JSON-LD Playground and in the RDF Translator, but the Structured Data Testing Tool throws errors on the @value objects, saying that the object provided "is not a known valid target type for the artMedium property" and also "is not a known valid target type for the fileFormat property."

{
"@context": "http://schema.org",
"@type": "VisualArtwork",
"artMedium": [
{"@value": "felt-tip pen"},
"http://vocab.getty.edu/aat/300410335"
],
"associatedMedia": [
{
"@type": "ImageObject",
"contentUrl": "http://example.org/myPic.jpg",
"fileFormat": {"@value": "image/jpeg"}
},
{
"@type": "ImageObject",
"contentUrl": "http://example.org/myPic.jp2",
"fileFormat": "https://www.iana.org/assignments/media-types/image/jp2"
}
]
}

It might be argued that this behavior is perhaps a shortcoming of the Structured Data Testing Tool, but for now we wanted a solution that avoided this issue altogether. Including an explicit @type for the non-URI objects is possible, e.g.:

"fileFormat": {"@value": "image/jpeg", "@type": "http://schema.org/Text"}

though this approach is handled reasonably by JSON-LD Playground and the RDF Translator, the approach did not seem to help with the Structured Data Testing Tool (we tried a few @type options), although the error message changes slightly, e.g., "The property @value is not recognized by Google for an object of type Text".

The work around that works optimally across all of the tools we're using (but I don't know about the implications for OWL processors) starts with redefining the properties of interest to leave off any explicit type, and then, when a URI is needed as value, to use an object with @id property - So:

{
"@context": [
"http://schema.org",
{
"s": "http://schema.org/",
"artMedium": {"@id": "s:artMedium"},
"fileFormat": {"@id": "s:fileFormat"}
}
],
"@type": "VisualArtwork",
"artMedium": [
"felt-tip pen",
{"@id": "http://vocab.getty.edu/aat/300410335"}
],
"associatedMedia": [
{
"@type": "ImageObject",
"contentUrl": "http://example.org/myPic.jpg",
"fileFormat": "image/jpeg"
},
{
"@type": "ImageObject",
"contentUrl": "http://example.org/myPic.jp2",
"fileFormat": {"@id": "https://www.iana.org/assignments/media-types/image/jp2"}
}
]
}

We did experiment with redefining the properties to be of type Text, e.g.:
"artMedium": {"@id": "s:artMedium", "@type": "s:Text"},
"fileFormat": {"@id": "s:fileFormat", "@type": "s:Text"}

But again, this would be inconsistent with the definitions of the many Text-only properties in the schema.org context document and we found that it results in explicit typing being added when the JSON-LD is translated, so we decided against doing this.

The only drawback to using @id when URI values are wanted is that the Structured Data Testing Tool then reports each of the URI values as an "Unspecified Type". This can be avoided by adding explicit types:

{
"@context": [
"http://schema.org",
{
"s": "http://schema.org/",
"artMedium": {"@id": "s:artMedium"},
"fileFormat": {"@id": "s:fileFormat"}
}
],
"@type": "VisualArtwork",
"artMedium": [
"felt-tip pen",
{"@id": "http://vocab.getty.edu/aat/300410335", "@type": "s:URL"}
],
"associatedMedia": [
{
"@type": "ImageObject",
"contentUrl": "http://example.org/myPic.jpg",
"fileFormat": "image/jpeg"
},
{
"@type": "ImageObject",
"contentUrl": "http://example.org/myPic.jp2",
"fileFormat": {"@id": "https://www.iana.org/assignments/media-types/image/jp2", "@type": "s:URL"}
}
]
}

But as far as we can tell (not sure about this), it doesn't buy you anything with the Structured Data Testing Tool, and it adds extra triples to the translation that are not needed (nor wanted) - the value of "@id" is already recognized by JSON-LD processors as a URI, just as a quoted value with no further typing is recognized by these tools as a quoted string value.

The trade-off of forcing the use of @id is an issue and has backwards compatibility issues, but especially when Text values are common this seems no worse than forcing the use of @value. Given that @value doesn't sit well with the Structured Data Testing Tool, we are for now going with the approach of over-riding the schema.org context document for these 5 properties. Not sure at this point if this issue can still be dealt with by changes to the schema.org context document.

[1] - http://rdf-translator.appspot.com/
[2] - http://json-ld.org/playground/
[3] - https://search.google.com/structured-data/testing-tool

from schemaorg.

Seems that whatever was tried did not work somewhere.
Did you try:

"artMedium": {"@id": "s:artMedium", "@type": ["s:Text","s:URL"]},
"fileFormat": {"@id": "s:fileFormat", "@type": ["s:Text","s:URL"]}

I seem to remember some discussion on these lines a while back but can't remember why that wasn't used.

from schemaorg.

Did try redefining this way, but all the json-ld tools say "unhashable type: 'list'", which I think is the right error message. I don't think you can use a list to define type of a key. Too bad, it would be a nice solution.

And to be clear, where okay where we ended up. When you have a property that can be either a simple string value or a URI in json-ld, the price you pay is having to use either @id or @value. Personally I think this is okay, especially if you alias id for @id to keep down the number of @s required (I think this may be on the list of possible context changes). Personally, I'd prefer to add the @id rather than mess with @value, but there are ample advocates the other way.

from schemaorg.

@tcole3 wrote:

@gkellogg and others have noted that there are work-around options, but we've noted that various tools make different assumptions and have different levels of tolerance for these workarounds, as illustrated below. For our use cases, for the tools we are focused on, we found that the best option was to redefine in our graphs the properties of interest to have no type (which is the way schema.org properties that can only have Text values, e.g., name, are defined in the context document). Having done this, when we can / need to supply a URI value, we do so using objects having an @id property (we can but do not include an @type property on these objects, though we don't know yet if this decision has implications for some tools).

Can you be more specific about this and give an example where tools perform differently? (didn't see anything in previous comments). Any tool that purports to support JSON-LD, and does not treat {"@value": "Text"} as a literal is totally non-conformant. JSON-LD has an exhaustive test suite, and the specifications are quite clear on this.

That said, i stand by my statement that any property documented to take either and IRI or Text should not use @type: @id in the context. That leaves many properties that really should only take an IRI that aren't defined that way.

from schemaorg.

We first tried this:
"artMedium": "felt-tip pen"

But the schema.org context document says this about artMedium:
"artMedium": { "@id": "schema:artMedium", "@type": "@id"}

If we include a reference to this context, both the json-ld playground and the rdf translator assumed the string "felt-tip pen" to be a fragment IRI, not a literal. However, the Google Structured Data Testing Tool, looks to be treating "felt-tip pen" as a literal. Apparent inconsistency.

We next tried both of the following formulations, but the Structured Data Testing Tool threw errors:

"artMedium": {"@value": "felt-tip pen"}
Error message from Structured Data Testing Tool (last line in red):

artMedium    
                   is not a known valid target type for the artMedium property.

"artMedium": {"@value": "felt-tip pen", "@type": "s:Text"}
Error message from Structured Data Testing Tool (last line in red):

artMedium
    @type     Text
    @value    felt-tip pen (The property @value is not recognized by Google for an object of type Text.)

Both json-ld playground and the rdf translator recognized these formulations as a literal and a string of type schema:Text, respectively; not sure what the Structured Data Testing Tool thinks these are, but it doesn't like them. Apparent inconsistency.

So while I cannot say with certainty that the Google Structured Data Testing Tool is failing to treat values of @value as a literal or an explicitly typed value, it does seem to have some kind of problem with the use of @value. We tried other options for typing the object containing @value, but none fared any better.

As it happens, the Structured Data Testing Tool does not have an analogous problem with @id, which led us to the solution we are implementing. So the Tool (and everything else) seems happy with the following:

"artMedium": {"@id": "http://vocab.getty.edu/aat/300410335"}

No inconsistencies, we just have to redefine properties of interest in local context and be sure to use @id for an IRI values of these properties.

The only other thing we've considered is not referencing schema.org as a context, but rather going with
"@context": {"@vocab": "http://schema.org/"}
But there are some context definitions we want, e.g., for sameAs which must always be a URL.

Personally, I agree with you that "any property documented to take either an IRI or Text should not use @type: @id in the context", but I understand the counter-argument (having lived through a number of heated discussions about this in another venue), and now there is also an existing base of JSON-LD schema.org out there to consider. If the Structured Data Testing Tool could handle @value the way we would expect, I'd be happy with that approach. But since it doesn't the only thing we've come up with is to redefine the properties we need in local context and use @id as necessary. I'm all ears if there's a better option.

from schemaorg.

@gkellogg I tried to paste {"@value": "felt-tip pen"} snippets from #51 (comment) in http://linter.structured-data.org/ but it gives

No structured data detected.

While JSON-LD playground parses same snippet just fine

from schemaorg.

Indeed, for some reason, the Linter doesn't detect it, I ran with the following:

{
  "@context": "http://schema.org",
  "@type": "VisualArtwork",
  "artMedium": [
    {"@value": "felt-tip pen"},
    "http://vocab.getty.edu/aat/300410335"
  ],
  "associatedMedia": [
    {
      "@type": "ImageObject",
      "contentUrl": "http://example.org/myPic.jpg",
      "fileFormat": "image/jpeg"
    },
    {
      "@type": "ImageObject",
      "contentUrl": "http://example.org/myPic.jp2",
      "fileFormat": "https://www.iana.org/assignments/media-types/image/jp2"
    }
  ]
}

However, if you run at http://rdf.greggkellogg.net/distiller (using the same tool set), you can see that it does produce RDF (Turtle) output:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix schema: <http://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

 [
     a schema:VisualArtwork;
     schema:artMedium <http://vocab.getty.edu/aat/300410335>,
       "felt-tip pen";
     schema:associatedMedia [
       a schema:ImageObject;
       schema:contentUrl <http://example.org/myPic.jpg>
     ],  [
       a schema:ImageObject;
       schema:contentUrl <http://example.org/myPic.jp2>;
       schema:fileFormat <https://www.iana.org/assignments/media-types/image/jp2>
     ]
 ] .

I'll investigate the linter issue, may need some library updates.

from schemaorg.

The Linter only accepts HTML input, meaning that the JSON-LD needs to be surrounded by <script> tags:

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "VisualArtwork",
  "artMedium": [
    {"@value": "felt-tip pen"},
    "http://vocab.getty.edu/aat/300410335"
  ],
  "associatedMedia": [
    {
      "@type": "ImageObject",
      "contentUrl": "http://example.org/myPic.jpg",
      "fileFormat": "image/jpeg"
    },
    {
      "@type": "ImageObject",
      "contentUrl": "http://example.org/myPic.jp2",
      "fileFormat": "https://www.iana.org/assignments/media-types/image/jp2"
    }
  ]
}
</script>

Try that in the linter.

from schemaorg.

That works, thanks!

The SDTT is clearly capable of dealing with literal values, so it's not clear what's going on here, but IMHO, the problem is with SDTT, not the vocabulary definition. As I said earlier, the context should not use @type: @id when schema:Text is in the range.

Maybe to improve schema.org handling across various tools, it needs some specific tests besides general RDF tests available at https://w3c.github.io/rdf-tests/ ?

from schemaorg.

There are three pertinent test suites:

• JSON-LD - http://json-ld.org/test-suite/
• RDFa - http://rdfa.info/test-suite/ (this has some issues that need attention)
• Microdata RDF - http://w3c.github.io/microdata-rdf/tests/

These are designed for interoperability/conformance testing of processors which purport to support the formats. I'm sure the SDTT team is aware of them.

The rdf-tests handle other formats, not directly supported by SDTT AFAIK.

from schemaorg.

@elf-pavlik Regarding the last paragraph in your comment: Can the schema.org JSON-LD context be used and overwritten in such situations?

from schemaorg.

I would say that whoever expects to have control over objects in statements getting interpreted as IRI or as Literal needs to take responsibility oneself for ensuring that JSON-LD document captures it as intended. No matter if one relies on @id and @value in the objects of statements, or @type in the @context definitions, or both.
I don't think anyone for who needs that clear distinction between IRIs and Literals should hope that simply using schema.org JSON-LD context will take care of it.

from schemaorg.

‘myschemaupdates‘ or a complete alternative could be provided by schema.org: ‘schema.org/context_for_linked_data_experts_who_know_what_they_are_doing‘

from schemaorg.

Maybe someone from http://schema.rdfs.org/ would like to pick the effort again or someone try to take over that project https://github.com/mhausenblas/schema-org-rdf

from schemaorg.

I would like to bring up this issue again. While @elf-pavlik 's approach (see comment) works for the translators I've tested, the approach springs an error in Google's Structured Data Testing Tool. Here's the error I receive: is not a known valid target type for the genre property. This was tested on schema:genre.

I also tried @gkellogg 's approach (see comment), using @value instead of @id. This brought up an error in Google's tool: There was an invalid type in your JSON-LD. RDF Translator translated this from JSON-LD to Turtle as:

schema:genre "Architectural photographs"^^<http://schema.org/@value>,
        "Photographs"^^<http://schema.org/@value> ;

RDF Validator and Converter sprung an error: Validation Failed: invalid type mapping: @value

We intend to use the Schema.org data we generate for both SEO purposes through Google et al, as well as within a local system, so a solution that works for both would be ideal.

from schemaorg.

@eightBitter by using @value, I meant as the value of a property. For example:

{
  "@context": ["http://schema.org", {
    "url": {"@type": "@id"}
  }],
  url: {"@value": "Something which is not a URL"}
}

from schemaorg.

@gkellogg thanks for the clarification. Your approach certainly works for the translators I've tested. However, it still brings up errors when validating through Google's Structured Data Testing Tool. Here's the example I ran through the tool:

{
  "@context": ["http://schema.org", {
    "genre": {"@type": "@id"}
  }],
  "@type": "CreativeWork",
  "name": "Title of the creative work",
  "genre": {"@value": "Something which is not a URL"}
}

I'm aware that this is probably a limitation of the tool itself. However, I did want to exhaust all possibilities of using the same data for two separate use-cases rather than having to manipulate the data to meet both use-cases.

from schemaorg.

Hi,
I have closed the following issue on Java JSON-LD repository:

jsonld-java/jsonld-java#248

The assessment is it is an issue with the schema.org context file. The workaround in that case is to pre-populate the cache for schema.org with a 'modified' context file.

from schemaorg.