On 11 Jun 2011, at 21:21, Giovanni Tummarello wrote: > will you be posting this as a FAQ i think its definitely worth it.
Good idea, thanks. Some of the answers are now here: http://schema.rdfs.org/faq.html Richard > > Gio > > On Sat, Jun 11, 2011 at 6:55 PM, Richard Cyganiak <[email protected]> wrote: >> All, >> >> Thanks for the thoughtful feedback regarding schema.rdfs.org, both here and >> off-list. >> >> This is a collective response to various arguments brought up. I'll >> paraphrase the arguments. >> >>> Limiting ranges of properties to strings is bad because we LD people might >>> want to use URIs or blank nodes there. >> >> Schema.org says the range is a string, and the RDFS translation reflects >> this. We tried to formally describe schema.org in RDFS. We did not try to >> make a fork that improves upon their modelling. That might be a worthwhile >> project too, but a different project. >> >>> Schema.org documentation explicitly say that you can use a text instead of >>> a Thing/Person/other type. >> >> This is the opposite case from the one above: They say that in place of a >> resource, you can always use a text. That's ok—we didn't say that >> schema:Thing is disjoint from literals. (I'm tempted to add “xsd:string >> rdfs:subClassOf schema:Thing.” to capture this bit of the schema.org >> documentation.) >> >>> The range should use rdfs:Literal instead of xsd:string to allow language >>> tags. >> >> That's a good point. The problem is that xsd:string is too narrow and >> rdfs:Literal is too broad. RDF 1.1 is likely to define a class of all string >> literals (tagged and untagged), we'll use that when its name has been >> settled, and perhaps just leave the inaccurate xsd:string in place for now. >> >>> You should use owl:allValuesFrom instead of the union domains/ranges. >> >> Probably correct in terms of good OWL modelling. But the current modelling >> is not wrong AFAICT, and it's nicer to use the same construct for single- >> and multi-type domains and ranges. >> >>> Nothing is gained from the range assertions. They should be dropped. >> >> They capture a part of the schema.org documentation: the “expected type” of >> each property. That part of the documentation would be lost. Conversely, >> nothing is gained by dropping them. >> >>> You should jiggle where rdfs:isDefinedBy points to, or use wdrs:describedby. >> >> >> This could probably be done better, but the way we currently do it is >> simple, and not wrong, so we're a bit reluctant to change it. >> >>> You're missing an owl:Class type on the anonymous union classes. >> >> Good catch, fixed. Thanks Holger! >> >>> You should add owl:FunctionalProperty for all single-valued properties. >> >> The schema.org documentation unfortunately doesn't talk about the >> cardinality of properties. Using heuristics to determine which properties >> could be functional seems a bit risky, given that it's easy to shoot oneself >> in the foot with owl:FunctionalProperty. >> >>> There are UTF-8 encoding problems in comments. >> >> Fixed. Thanks Aidan! >> >>> You should mint new URIs and use http://schema.rdfs.org/Thing instead of >>> http://schema.org/Thing. >> >> >> Schema.org defines URIs for a set of useful vocabulary terms. The nice thing >> about it is that the URIs have Google backing. The Google backing would be >> lost by forking with a different set of URIs. >> >>> You should mint new URIs because the schema.org URIs don't resolve to RDF. >> >> >> Dereferenceability is only a means to an end: establishing identifiers that >> are widely understood as denoting a particular thing. Let's acknowledge >> reality: Google-backed URIs with HTML-only documentation achieve this better >> than researcher-backed URIs which follow best practices to a tee with a >> cherry on top. >> >>> You are violating httpRange-14 because you say that http://schema.org/Thing >>> is a class, while it clearly is an information resource. >> >> Schema.org documentation uses these URIs as classes and properties in RDFa. >> They also return 200 from those URIs. So it's them who are violating >> httpRange-14, not us. Draw your own conclusion about the viability of >> httpRange-14. >> >>> You should use http://schema.org/Thing#this. >> >> >> Schema.org is using http://schema.org/Thing as a class in their RDFa >> documentation. I don't think we should mint different URIs in their >> namespace. >> >>> http://schema.org/Person is not the same as foaf:Person; one is a class of >>> documents, the other the class of people. >> >> I don't think that's correct at all. http://schema.org/Person is the class >> of people and is equivalent to foaf:Person. It's just that the schema.org >> designers don't seem to care much about the distinction between information >> resources and angels and pinheads. This is the prevalent attitude outside of >> this mailing list and we should come to terms with this. >> >> Best, >> Richard >> >
