Re: blank nodes with (name || description) vs. rangeIncludes: Text

On Sep 30, 2014, at 4:09 AM, ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org> wrote:

> Howdy,
> 
> I started writing script for converting microformats2 JSON[1] into
> JSON-LD. Microformats gave me impression (which may change) of using
> URIs and textual labels in bit confusing way, it also uses implied
> properties[2]. This reminded me about schema.org issue #51 on github -
> "JSON-LD context problem for properties that can take both URL or Text"[3]
> 
> I would like to know what people thing about recommending use of *blank
> nodes* with schema:name properties instead of specifying
> schema:rangeIncludes schema:Text
> 
> Following http://schema.org/namedPosition example
> 
> {
>  "@context": "http://schema.org",
>  "@type": "SportsTeam",
>  "name": "San Francisco 49ers",
>  "member": {
>    "@type": "OrganizationRole",
>    "member": {
>      "@type": "Person",
>      "name": "Joe Montana"
>    },
>    "namedPosition": "Quarterback"
>  }
> }
> 
> becomes
> 
> {
>  "@context": "http://schema.org",
>  "@type": "SportsTeam",
>  "name": "San Francisco 49ers",
>  "member": {
>    "@type": "OrganizationRole",
>    "member": {
>      "@type": "Person",
>      "name": "Joe Montana"
>    },
>    "namedPosition": {
>      "name": "Quarterback"
>    }
>  }
> }
> 
> This way pretty much everything with at least rangeIncludes: Thing could
> use blank node with has free form text in *description*
> 
> {
>  "@context": "http://schema.org",
>  "@type": "Article",
>  "license": {
>    "description": "You need to suffer and read this license text
> yourself because I didn't use URI of some commonly recognized license :P"
>  }
> }
> 
> I must admit also not getting difference between rangeIncludes: URL and
> rangeIncludes: Thing . I understand that we always can choose if we
> provide URL directly or embed object with { "@id": "..." }
> 
> Opinions?

This is the logic the Structured Data Linter uses: that a property value which is a string when the range of the property is an object, is equivalent to saying that the value is actually a node having the property schema:name with the original string value. This also allows you to infer the type of the node, in the case that there is only a single class specified in rangeIncludes. (Well, that's the intent, if not the letter of the implementation right now).

For this reason, I have felt that it doesn't make sense from a data model perspective to includes schema:Text in the range of a property which also has some other schema:Thing in it's range.

The thing that argues against this, though, is if the JSON-LD context should describe the property as having a @type, or not. If the range includes schema:Text, you could then infer that the context term definition should not include @type. This isn't the logic now, but it could be a way to allow strings to be interpreted as IRIs for properties who's range is a kind of schema:Thing.

Gregg

> [1] http://microformats.org/wiki/microformats2
> [2] http://microformats.org/wiki/microformats-2-implied-properties
> [3] https://github.com/rvguha/schemaorg/issues/51
>

Received on Tuesday, 30 September 2014 16:09:48 UTC