Fwd: Re: Error in schema.org context or are we overlooking something ? Re: first user story for SoLiD & schema + v-card feedback

Forwarding a reply from Dan Brickley.

Cheers,
Andreas

-------- Forwarded Message --------
From: Dan Brickley <danbri@danbri.org>
To: Andreas Kuckartz <a.kuckartz@ping.de>
Cc: Henry Story <henry.story@bblfish.net>, Harry Halpin
<hhalpin@ibiblio.org>

fwiw my reply bounced since i'm not on that list apparently

On 3 May 2015 at 13:58, Dan Brickley <danbri@danbri.org> wrote:
> On 3 May 2015 at 12:18, Andreas Kuckartz <a.kuckartz@ping.de> wrote:
>> henry.story@bblfish.net wrote:
>>> So when one looks at the example of schema:Person and translates it
>>> to RDF one is pretty schocked to see:
>>>
>>> []  a :Person;
>>>     :address  [
>>>                  a :PostalAddress;
>>>                  :addressLocality "Seattle";
>>>                  :addressRegion "WA";
>>>                  :postalCode "98052";
>>>                  :streetAddress "20341 Whitworth Institute 405 N. Whitworth"
>>>      ];
>>>      :colleague "http://www.xyz.edu/students/alicejones.html",
>>>                 "http://www.xyz.edu/students/bobsmith.html";
>>>      :email "mailto:jane-doe@xyz.edu";
>>>      :image <http://json-ld.org/playground/janedoe.jpg>;
>>>      :jobTitle "Professor";
>>>      :name "Jane Doe";
>>>      :telephone "(425) 123-4567";
>>>      :url <http://www.janedoe.com> .
>>>
>>>
>>> So the postal address if fine, but the colleague as a link to a string
>>> representing a document is a complete no go for SoLiD. This means that
>>> SoLiD applications would need to guess now if a string was meant as a URL.
>>> How would that function for relative URLs? Would one have to try to
>>> dereference each name as a relative URL first before then trying to
>> display
>>> it?
>>
>> To me that looks as if there is an error somewhere and that the two
>> strange lines should be:
>>
>>       :colleague <http://www.xyz.edu/students/alicejones.html>,
>>                  <http://www.xyz.edu/students/bobsmith.html>;
>>
>> The documentation states that the "Expected Type" for "colleague" is
>> "Person" but the JSON-LD context delivered from http://schema.org does
>> not say anything about "colleague".
>>
>> Maybe Dan can resolve this?
>
> JSON-LD imposes awkward distinctions which don't map well to the
> thing-or-string flexibility of schema.org properties, however the
> context-amended defaults can be over-riden locally. We anticipate that
> many properties (such as 'colleague') will be used in descriptions
> where an inline description is used, e.g. a Person. We do generally
> not make a fuss if a string is supplied instead.
>
> Currently we don't set type to @id if a property anticipates a general
> Thing subtype, unless it is explicitly set to anticipate URL values.
> URL is a little odd in schema.org's system since it looks
> superficially like "a kind of Text string that is an URL" but really
> serves more as a hint that the property might be written using remote
> entity references.
>
> https://github.com/schemaorg/schemaorg/blob/sdo-gozer/api.py#L665 is
> the code if you're curious.
>
> Probably your best work around for these cases is { "@id":
> "http://example.com" }. If there are a lot of them we could consider
> tweaking the context in cases where strings are unlikely/unwelcome
> (easiest way would be by adding URL as an expected type).
>
> Dan

Received on Sunday, 3 May 2015 13:26:50 UTC