- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Wed, 15 Jun 2011 11:16:13 +0100
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- Cc: Pat Hayes <phayes@ihmc.us>, Linked Data community <public-lod@w3.org>, Michael Hausenblas <michael.hausenblas@deri.org>
On 15 Jun 2011, at 02:25, Alan Ruttenberg wrote: > There is no reason to assume that parsing schema.org formatted syntax > should be a trivial transformation to triples. There is a W3C specification in Last Call status that defines how the syntax used by schema.org should be transformed to triples [1]. Best, Richard [1] http://www.w3.org/TR/microdata/#rdf > I would handle the > string thing at parsing time. First note that every schema.org thing > can have a url property. That's what the uri ref would be made from > for the (non string) resource. We need to handle several cases then, > since the (syntactic) object of an object property assertion (a uri > ref) might or might not reasonably be constructed from the surface > value (yes when entity and the url property value is specified). So in > the case where the range of a property is a non-string entity: > > If the surface value is an entity, and there is a url property > specified then it is used to construct the uri-ref for the object > position. If there is no url property then you use a bnode in the > object position. > One infers (or simply asserts in translation) that the entity is of > type specified by the range. > One asserts the rest of the entity properties (I would map "name" to > rdfs:label, personally). > > If the surface value is a string, then a bnode is used in the object position. > One infers (or simply asserts in translation) that the entity is of > type specified by the range. > One asserts in the translation that the rdfs:label of the entity is > the surface value string. > > If there are some properties that *legitimately* can either be strings > or (non-string) entities then we have ambiguity. I haven't reviewed > schema.org to see whether this happens, but the cases where the value > of some property are *truly* a literal (not *defined* as a literal but > actually carrying an entity label or encoding or whatnot) are, I > suspect, easy to identify, and the bold claim would be that the > legitimate literals would rarely be acceptable as property values > alongside entities. > > One cares about this also because schema.org is incomplete, so there > are many properties whose ranges are currently declared as text, but > for which one can expect that there will eventually be entity > definitions. E.g. on CreativeWork: awards, currently: Text, Awards won > by this person or for this creative work. It's not that much of a > stretch to think someone will want to define an award entity that has > properties that relate it to the granting organization, the date > awarded, etc. > > The bottom line is that with some ( dare i say it ;-) ) relatively > simple ontological analysis of the schema.org schemas, and with the > translator from html to rdf written to take account of that analysis > (by using bnode objects for properties whose objects are not sensibly > literals), we don't need to accept the broken every-range-is-a-string. > > -Alan > > ps. I've heard those who want a "simple" rdfs translation, so you > don't have to remind me. That doesn't strike me as a particularly good > idea to me atm, so I'll keep discussing the alternative, thank you. >
Received on Wednesday, 15 June 2011 10:16:46 UTC