W3C home > Mailing lists > Public > public-socialweb@w3.org > May 2015

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

From: <henry.story@bblfish.net>
Date: Sun, 3 May 2015 17:31:34 +0200
Cc: Andreas Kuckartz <a.kuckartz@ping.de>, Social Web Working Group <public-socialweb@w3.org>, Dan Brickley <danbri@danbri.org>
Message-Id: <BCCAB7ED-458F-4D91-A8D7-6D980679990F@bblfish.net>
To: Elf Pavlik <perpetual-tripper@wwelves.org>

> On 3 May 2015, at 15:44, ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org> wrote:
> 
> On 05/03/2015 01:18 PM, Andreas Kuckartz 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".
> 
> to my understanding schema.org makes two decisions which IMO might catch
> people used to RDF by surprize. saying in JSON-LD terminology
> 
> it doesn't map in JSON-LD context "url": "@id"
> * https://github.com/schemaorg/schemaorg/issues/410
> 
> so pretty much everything becomes a blank node but with url property
> which has special meaning only from schema.org perspective

perhaps that is a good thing. In that case the blank node correctly identifies the person, and people who don't know about the meaning of @id, correctly identify the object via the "url" relation.

> 
> it doesn't clearly distinguish ObjectProperty and DataProperty, so very
> little properties have in JSON-LD context "@type": "@id", which results
> in of the shelf processor treating URIs as strings - and using @value
> instead of @id

I think it would be difficult to do that other than on a case by case basis,
as Dan Brickley points out.

> 
> we could look at some kind of *polyfill* approach, so one could still
> reuse schema.org URIs but put more restrictions on publishers
> 
> last but not least that "thing-or-string flexibility of schema.org
> properties" resembles in to me what Microformats also seems to do! we
> should definitely investigate it further and decide if it also matters
> for the context we work with here...
> 
> cheers

Social Web Architect
http://bblfish.net/
Received on Sunday, 3 May 2015 15:32:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:26:17 UTC