Re: Primer: some vocabulary questions

  Graham Klyne wrote:

> 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.)


Graham--

I think the way I phrased these questions might have misled you into 
addressing more detailed issues than I was really after.  Let me try 
again.  I am trying to address *in the Primer* (i.e., for readers of the 
Primer, not for people who, for example, understand the ramification of 
"typed nodes") something about the separation of RDF from RDFS, which 
has always been somewhat blurred, but may be more blurred now.  E.g., to 
say what a processor/application that understands "RDF" must be capable 
of dealing with, versus one that also understands "RDFS", and how 
separate those things really are.  One obvious way to characterize this 
would be to say that an "RDF" processor must understand (or at least not 
complain about) all the stuff in the rdf: namespace.  Is that 
reasonable?  Here I'm not trying (I don't think) to describe anything as 
detailed as "error behavior", but make a rough characterization of how 
things are divided up.


> 
>> 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:


Here, I'm not concerned with notions of validity.  Among other things, 
I'm concerned that someone may read the schema document and get confused 
(against which I'd like to inoculate them in the Primer if I can), 
because (in apparent contrast with anything we might have said about 
question 1) there are these lists of "RDF Core Classes and Properties" 
in the schema document, many of which come from the rdfs: namespace, and 
hence which a vanilla RDF processor (i.e., one that doesn't also process 
RDFS) might not be expected to understand.  So I'd like suggestions on 
how to characterize such "RDF Core classes" that are, nevertheless, not 
in the rdf: namespace.


> 
> [[
> 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.
> 


Again, I don't mean to talk about limiting users (and I am giving people 
the advice you mention).  It's the mixing of the definitions (and the 
consequences) that I'm wondering about.  What I was getting at was that, 
while rdf:type is defined in the rdf: namespace, the (apparent) 
semantics are given in the schema document.  Moreover, imagine someone 
who thinks RDFS is sort of optional;  they want to "just write RDF" 
(like someone who just wants to write XML might think an XML Schema is 
optional).   So they use rdf:type (which is "just RDF") with values that 
they perhaps intend to represent types in some type notion they have in 
their heads, but without necessarily intending them to be interpreted as 
RDFS classes (with all their associated semantics).  Someone else comes 
along with an RDFS processor, processes those rdf:type declarations 
("it's RDF right?  it must be OK to process it with RDFS"), which 
complains a lot or (possibly worse) draws a lot of unintended 
inferences.  In your response, you said "What RDFS actually does is 
allow us to infer that anything at the pointy end of rdf:type is a 
member of rdfs:Class."  I agree;  but, for example, don't you think we 
ought to warn people who use rdf:type but don't necessarily intend to 
use RDFS, thinking they are different languages, that, if their RDF is 
processed with an RDFS processor, those inferences will be drawn?  Or, 
alternatively, ought I to say in the Primer that these languages are 
more intertwined than they may have been thought to be in the original 
M&S and Schema specs?  (What do we expect to happen if an OWL processor 
gets hold of those type references, "in the wild" so to speak?)

--Frank

 


-- 
Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875

Received on Wednesday, 17 July 2002 09:00:43 UTC