"processor" in RDF Primer [was: Re: "RDF processor"? "understand"??? ]

Actually, my original question didn't involve putting words into specs. 
However, now that Dan (both of them) have brought up the point, the term
"RDF processor" (or "processor" used in a way that would be taken to 
mean that) appears in the current version of the Primer (23 August 2002) 
in the following places.  If anyone wants to propose wording changes, 
I'll be happy to incorporate them.

--Frank


Section 3:
An RDF processor would form the complete URIref of the creation-date 
property from the QName <ex:creation-date> by converting the ex: prefix 
to the namespace URI defined for it in Line 3, and appending 
creation-date to it.

 
Section 3.1:

This could create a problem, since if an RDF processor retrieved the 
catalog from the mirror site, the URIref generated for our example tent 
would be http://mirror.example.com/2002/04/products#10245, rather than 
http://www.example.com/2002/04/products#10245, and hence apparently a 
different tent.

Section 4.1:
Note that the RDF/XML uses li as a convenience element to avoid having 
to explicitly number each membership property. The RDF processor will 
generate the numbered properties rdf:_1, rdf:_2, and so on from the li 
elements as necessary.

...

The examples above illustrate that the general structures of the RDF 
graphs for both Bags and Alternatives are the same (and they are also 
the same for Sequences); only the indicated rdf:type is different. RDF 
considers these types as essentially "hints" to a processing application 
on how to properly interpret the structures. This is because RDF 
processors are not in a position to control how an application actually 
uses these structures. For example, an RDF processor has no way to force 
an application to use the first member of an Alternative collection as a 
default value. Similarly, an RDF processor has no way to force an 
application to ignore order in processing a Bag.

RDF processors are also limited in their ability to enforce structural 
constraints on these collections. For example, these structures 
explicitly permit duplicate values. RDF does not define a Set container, 
which would be a Bag with no duplicates, because RDF processors are not 
necessarily in a position to enforce a no-duplicates constraint (for 
example, a duplicate might exist somewhere else on the web, unknown to 
the processor). Also, if you create the membership properties yourself, 
RDF does not insist that the property numbers be contiguous starting 
with rdf:_1. For example, you could create a legal Bag with just the 
membership properties rdf:_3, rdf:_7, rdf:_8, and rdf:_11 (although an 
RDF processor would not generate these property names from a collection 
of rdf:li properties).

Section 5:

RDF Schema uses the RDF data model itself to define the RDF type system, 
by providing a set of pre-defined RDF resources and properties, together 
with their meanings, that can be used to define user-specific classes 
and properties. These additional RDF Schema resources extend RDF to 
include a larger reserved vocabulary with additional meaning. These 
resources become part of the RDF model of any description that uses 
them, and extend the meaning of that description for any processor that 
understands the extended vocabulary.

Section 5.3:
Moreover, depending on how the processor interprets the property 
declarations, an instance might be allowed to exist either without some 
of the declared properties (e.g., you might have an instance of ex:Book 
without an ex:author property, even if ex:author is declared as having a 
domain of ex:Book), or with additional properties (you might create an 
instance of ex:Book with a xyz:technicalEditor property, even though you 
haven't defined such a property in your particular schema.)

In other words, RDF Schema declarations are always descriptions of RDF 
instance data. They may also be prescriptive (introduce constraints), 
but only if a processor interpreting those statements wants to treat 
them that way. All RDF Schema does is provide a way of stating this 
additional information. Whether this information conflicts with 
explicitly specified instance data is up to the processor to determine 
and act upon.

Section 6.3:
This allows XPackage to be implemented as a general XML application 
without an RDF processor, while still maintaining RDF compliance of 
conforming documents.



-- 
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 Friday, 23 August 2002 11:14:51 UTC