Schema LCC review

Typos, trivial stuff, one issue (which is raised here because you've
carefully not said much about seeAlso &co., so not necessarily a schema
problem)


1. Introduction

"As such, RDF data can resemble an entity-relationship diagram."

An instance diagram, maybe, but I think this sentence is empty and can
be struck. The traditional distinction between class and instance is
blurred by RDF.


2. Classes

"Note that if a class were the same thing as the set of its instances
then common (Zermelo-Fraenkel) set theory would prevent it being an
instance of itself."

This comes across more clearly in the MT; strike this sentence on the
grounds of being woolly.


"A class C is a subclass of a class C' if and only if all the instances
of C are also instances of C'."

Again, this is what the MT says, but I still find it incongruous that
classes have an intensional semantics yet the primary relationship
between them is extensional. I'd prefer a purely intensional definition:

"If a class C is a subclass of a class C', then all instances of C are
also instances of C'." See below.


2.1 rdfs:Resource

Formatting error. (no heading style?)


3.1 rdfs:range

"The triple

	P rdfs:range C

states that P is an instance of the class rdf:Property, that C is an
instance of the class rdfs:Class and that the objects of triples whose
predicate is P are instances of the class C."

All those things are true as a consequence of the semantics document
(since rdfs:range rdfs:domain rdfs:Property is an RDFS axiomatic triple)
but does this triple _state_ all those conclusions or does it _entail_
them? because it only RDFS-entails these conclusions, not rdf-entails
them. Same comments (I think) apply to 3.2 and 3.3 (consider this
preemptive nitpicking)


3.2, 3.3 Heading formatting error.


3.4 rdf:subClassOf

"...is used to state that one class is a specialization of another."

No it isn't; it's used to state a subset relationship between their
class extensions. You've carefully pointed out the difference between
two intensionally distinct classes with the same extension in section 2.
Don't ignore it here. Using your example, consider the class of everyone
living in the UK as collected bythe tax office. Can you honestly say
that the post office's class of people at a particular "zip code" is a
speciali[sz]ation of that?


5.2 RDF Collections

SEMANTICS doesn't require that the collections structures are
well-formed. Do you want to point that out here? What is your answer to
the question, "are RDF Collections required to be well-formed?"


5.4.1 rdfs:seeAlso

You carefully don't say much here, which is good. However, I think this
raises an issue which we should address (even if it's to punt) before or
as part of LC:

	If a resource is named by something that looks like a URI,
	then what expectations can we have about that? If we (through
	some process) dereference that URI, what can we expect to
	see? Ie, is there any expectation (and if so, when) that
	the use of a web address to name something means that we
	can get a description of the named thing by dereferencing that
	address? Or does the web address name the description
	itself?

Consider this a last-call comment (to speed things along, ie get to LC)
but I think we're doing the semantic web a disservice by not addressing
this question - even if "addressing" the question involves punting to
TAG. One explicit approach would be to introduce an explicit set of
properties along these lines:

	<eg:something> <rdfx:URI> "eg:something-else"^^<xsd:uri> .

Same comments apply to 5.4.2; although the wording is careful here too.


6.1 RDF classes

rdfs:Resource comment doesn't look like an English noun phrase.
rdf:List: "The class of RDF Lists." What's an RDF List? You've talked
about containers and collections. "The class of internal nodes/resources
in an rdf collection" maybe? Or something else, anyway.







-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
The Java disclaimer: values of 'anywhere' may vary between regions.

Received on Tuesday, 14 January 2003 07:03:41 UTC