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
