- From: <henry.story@bblfish.net>
- Date: Sun, 3 May 2015 17:31:34 +0200
- To: Elf Pavlik <perpetual-tripper@wwelves.org>
- Cc: Andreas Kuckartz <a.kuckartz@ping.de>, Social Web Working Group <public-socialweb@w3.org>, Dan Brickley <danbri@danbri.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