Re: Primer: some vocabulary questions

At 01:34 PM 7/16/02 -0400, Frank Manola wrote:
>1.  Must a processor that claims to understand "rdf" understand (i.e.,
>correctly do something with) everything in the rdf: namespace?  Or,
>putting it another way, if a processor barfs at something that *is* in
>the rdf: namespace, is there something wrong with it?  I understand that
>we've not fully dealt with stuff like conformance, but, for example, the
>RDF/XML spec enumerates the names in the rdf: namespace, and says that
>any other names are not defined and should generate a warning.  However,
>I couldn't find any productions that explicitly mention, e.g., Seq and
>Alt, so if someone builds an RDF/XML processor that flags those names,
>is it wrong?  To repeat, I'm mainly asking about this not as commentary
>on RDF/XML, but as a question about what it means to be an "rdf
>processor" (a similar question could be asked about "rdfs processor").

I think this touches on the difficulty of trying to specify error 
behaviour.  I'd say that if an  RDF processor complains about rdf:Seq, 
etc., (which doesn't need to be mentioned explicitly in the syntax because 
it's now covered as a typed node, right?), then it's not fully RDF.

The RDF namespace is special because we want to keep open the option for 
future RDF working groups to use rdf: URIs in a syntactic 
fashion;  reserving unrecognized RDF terms ensures that such extensions 
won't conflict with possible attempts to use them as additional properties 
and/or values.  (Is the same true of rdfs:?  I don't remember.)

>2.  A related issue involves the way the current Schema document unions
>rdf: and rdfs: terms into groups like "RDF Core Classes and
>Properties".  The problem is whether that might be misinterpreted to
>mean that an rdf processor must understand, say, rdfs:Resource,
>rdfs:isDefinedBy, rdfs:domain, rdfs:Class, and so on (because they're
>listed as "RDF classes" and "RDF Core classes"?  (I can appreciate that
>there may be no special semantics associated with some of these, so that
>as long as an rdf processor generates the appropriate triples when it
>encounters these terms, the graph will be OK, but is it supposed to
>complain or not complain when it sees these names?)

I don't think an RDF parser should ever complain simply because it sees a 
valid term it doesn't recognize.  (The rdf: namespace is different because 
it effectively says unrecognized rdf: terms aren't valid terms.)

However an RDF *application* may choose to impose some idea of validity 
that isn't defined by the RDF spec (e.g. there has been talk about having a 
CC/PP validator).  Here, it's up to the application to define its notion of 
validity and behave accordingly.  What I'm saying is this kind of thing is 
out of scope of the working group specification, but I think it might be 
helpful to add a comment like this to the primer, somewhere:

[[
Beyond describing a well formed graph, RDF does not define any notion of 
validity.  An application that uses RDF may wish to impose its own notion 
of validity;  e.g., an application may require that all properties and 
classes are used in ways that are specifically described by some available 
RDF schema.  Any such behaviour is an aspect of the application, not part 
of the RDF specification;  different applications may have wildly differing 
notions of validity, if they have any such notion at all.

Designers of applications that impose constraints on the accepted forms of 
RDF are advised to consider carefully whether their design would violate 
the "anyone can say anything about anythin" open-ended extensible nature of 
RDF.  One of the strengths of RDF is in allowing an application to use RDF 
information from a number of different sources, many of which may have been 
constructed without regard for any particular application.  For example, 
simply rejecting RDF containing vocabulary unrecognized by an application 
may unnecessarily limit the sources of RDF that it can usefully use.
]]

(If you've already got something like this, then fine -- I'm not checking 
the original Primer document as I write this.)

>3.  rdf:type is defined as having a range of rdfs:Class (the latter not
>being defined in the rdf: namespace), which again mixes the namespaces a
>bit.  Should it be made clear that people can write good RDF using
>rdf:type with a value that isn't a class (even if an rdfs processor that
>rigorously enforces schemas as constraints comes along later and
>complains)?  Or, to put this another way, should we be telling people
>that if they want to define types, even though rdf:type itself is in the
>RDF vocabulary, they ought to use the RDFS vocabulary to define what's
>at the other end of the arrow?

I think I may misunderstand the question...

I don't think we should be advising users to limit what is at the end of 
rdf:type.  What RDFS actually does is allow us to infer that anything at 
the pointy end of rdf:type is a member of rdfs:Class.

It's probably reasonable to advise people to use RDFS to describe their 
classes (and properties), but not say that it's always necessary to do this.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>

Received on Tuesday, 16 July 2002 20:16:55 UTC