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

On Fri, 2002-08-23 at 10:28, Frank Manola wrote:
> 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.

OK, here are some wording changes: strike all mention of 'RDF
processor' and 'processor'.

Rationale: The technical content of the primer must be a consequence
of the technical content of the other specs. None of the specs specify
what an "RDF processor" is.

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

Possible re-wording: the complete URI reference of the
creation-date property corresponding to the QName ex:creation-date
results from replacing the ex: prefix by the namespace URI
defined for it on line 3.

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

Change "RDF processor" to "user agent" or "client" or some
such generic term.


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

... each membership property. This syntax is short-hand for numbered
properties rdf:_1, rdf:_2, and so on.


> 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

anthropomorphism. Please avoid using 'RDF' as the subject
of active verbs.

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

I suggest striking those 3 paragraphs.

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


Strike the last sentence. (the phrase 'the RDF model of
any description' misuses the term 'model', too.)


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

Strike those two paragraphs.

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

Strike it. 'XML application' is no more specified than 'RDF processor'.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
office: tel:+1-913-491-0501

Received on Monday, 26 August 2002 09:41:06 UTC