- From: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>
- Date: Sun, 03 May 2015 15:44:35 +0200
- To: Andreas Kuckartz <a.kuckartz@ping.de>, public-socialweb@w3.org
- CC: danbri@danbri.org, Henry Story <henry.story@bblfish.net>
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 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 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
Received on Sunday, 3 May 2015 13:44:39 UTC