Re: Primer - review: WG please advise/comment!

Graham--

This is good material.  Comments interspersed below.

***NOTE FOR THE WG: there are some issues below that need either 
information from more knowledgeable members of the WG, or advice to me 
from the WG as to whether to add more material in certain sections.  So 
read on!

Graham Klyne wrote:

>

snip

> I do have some comments about this material, some of which I feel are 
> quite important to consider before we go to a final recommendation 
> status.  I've tried to offer text that I hope you can use (if we all 
> agree, of course).


Right.  Many of the points your raise are important;  in some cases, 
there is need for WG agreement (I've tried to indicate those points); 
in others, I can probably go ahead and make the appropriate changes.

>
snip
> 
> 
> My 1st comment is a real nit:  the "latest version" link actually points 
> to an older document !

Right.



> 
> Section 1
> ---------
> In the list of documents, delete "(and datatypes)" from the RDF schema 
> listing.


Well, I could always hope!


> 
> Section 2.1
> -----------
> The string distinction between URLs and URIs seems to against some other 
> W3C work:
>   http://www.ietf.org/internet-drafts/draft-mealling-uri-ig-02.txt
> [[
>    Further according to the contemporary view, the term "URL" does not
>    refer to a formal partition of URI space; rather, URL is a useful but
>    informal concept: a URL is a type of URI that identifies a resource
>    via a representation of its primary access mechanism (e.g., its
>    network "location"), rather than by some other attributes it may
>    have.
> ]]
> 
> I think this text goes against that viewpoint:
> [[
> The Web provides its own form of identifier for these purposes, called 
> the Uniform Resource Identifier (URI). URIs are similar to URLs, in that 
> different persons or organizations can independently create them, and 
> use them to identify things. However, unlike URLs, URIs are not limited 
> to identifying things that have network locations, or use other computer 
> access mechanisms. In fact, we can create a URI to refer to anything we 
> want to talk about, including
> ]]
> 
> I'd suggest something more like this:
> [[
> URLs, whose use in RDF is noted above, are a particular use of the 
> general Uniform Resource Identifier (URI) form of Web identifier.  URLs 
> share a number of general URI properties, in that different persons or 
> organizations can independently create them, and use them to identify 
> things.  URIs are not limited to identifying things that have network 
> locations, or use other computer access mechanisms. In fact, we can 
> create a URI to refer to anything we want to talk about, including
> ]]


I take your point.  I'd like to introduce the URI concept a bit more 
explicitly as something possibly-new to the reader than your suggested 
wording seems to do, but I agree that the URL should be identified as a 
special case of the more general URI concept.


> 
> Section 2.3
> -----------
> Your N-triples examples are split over several lines, which isn't 
> allowed for "real" N-triples (personally, I think line breaks should be 
> allowed, but tat's water under the bridge.)  Clearly, you need line 
> breaks to fit the examples on a page, so I think the introduction to 
> N-triples should make this point.
> 
> [[
> As defined, each statement expressed in N-triples must occupy a single 
> line of a file.  But if long URIs are used, such lines can get very 
> long, so for the purpose of presentation in this document, the three 
> parts of an N-triple are placed on separate lines, as shown below.
> ]]
> (insert somewhere soon after figure 2.)


Agreed (someone else complained about this too), although I'd raise a 
slight nit:  what's forbidden in triples is extraneous characters like 
line breaks, not that a triple can't appear on multiple lines *in a 
display* (write a triple across one line and then narrow the browser 
window sufficiently and you'll see what I mean).  But the text you've 
provided should do very well.


> 
> Section 3
> ---------
> Description of rdf:ID.  I had a vague idea that we'd decided that rdf:ID 
> wasn't for new resources, but simply a syntactic variation with similar 
> meaning to rdf:about.
> 
> In particular, is the following RDF legal?:
> 
> <rdf:RDF xmlns:rdf= ... >
> 
>    <rdf:Description rdf:ID="foo">
>       <ex:prop1>value1</ex:prop1>
>    </rdf:Description>
> 
>    <rdf:Description rdf:ID="foo">
>       <ex:prop2>value2</ex:prop2>
>    </rdf:Description>
> 
> </rdf:RDF>
> 
> I thought it (now) was, but the current primer text suggests not.
> 


The following appears as a constraint in the idAttr production of the Syntax spec:

"The names used as values of rdf:ID and rdf:bagID attributes must be 
unique in a single RDF/XML document since they come from the same set of 
names. This applies with respect to the in-scope base-uri property of 
the current element; so the same value can appear on different elements 
in the same document but only if the in-scope base-uri values were 
different".  Also, the idAttr and aboutAttr productions are sufficiently 
different so I thought they weren't simply variants of each other 
(although I could be misreading this).
***Anyone know what the right interpretation here is?***


> 
> Section 4 seems to be missing any discussion of the other abbeviated 
> syntax forms allowed by RDF.  I think the primer should cover at least 
> some of these, especially:


I assume you mean Section 3 (on the RDF/XML syntax;  Section 4 is on the 
Schema).
***This is something I'd like WG input on***.  I'm quite willing to 
include this discussion, but I'm getting other vibes that suggest the 
Primer is getting too long as it is.


> 
> (a) use of a type name in place of <rdf:Description>


I discuss an example of this abbreviation in Section 4.2.  The problem 
here is that I didn't want to discuss this until after I'd introduced 
the "type" property (and the whole notion of things having types), which 
doesn't come until the Schema section.


> 
> (b) use of attributes rather than elements to encode properties.
> 
> In particular, I think it would be useful to show, early on, how RDF/XML 
> syntax can look very much like "ordinary" XML.  Here's an example of the 
> sort of thing that might be added at the end of section 3 (with 
> apologies for the immodest choice of topic -- I just happened to have 
> some RDF data for that lying around):


I agree that this would be useful,
***modulo the WG agreeing too!***


> 
> [[
> The basic structure for encoding an RDF graph in XML has been described 
> above.  This is completely sufficient for describing any graph that can 
> be described using the RDF/XML syntax, but can sometimes seem unwieldy 
> and difficult to understand.  The RDF/XML syntax also provides some 
> alternative forms that allow some graphs to be expressed more compactly, 
> or in a fashion that is more familiar to many XML users.
> 
> 1. The name of an <rdf:Description> element can be replaced by an RDF 
> class name (RDF classes are described more fully in section 4.1).  This 
> is equivalent to writing an <rdf:Description> element containing a 
> corresponding <rdf:type> property in addition to all the other contained 
> properties.
> 
> 2. Non-repeating properties with literal values can be written as 
> attributes of the containing description.
> 
> 3. When describing a property value that is itself a resource, 
> properties of the target resource's attributes can be added as 
> attributes of the property element referencing that resource.
> 
> Using the abbreviated form (1), the following is legitimate RDF:



snip



> 
> These three examples all describe exactly the same RDF graph, viz:
>   <<<graph diagram>>>
> 
> Using these abbreviation forms, it is possible to write RDF data that is 
> also quite recognizable as XML data.
> ]]
> 
> 
> Section 4
> ---------
> 
> I think the introduction to the type system weighs too heavily on 
> schemas as constraints (which IMO is one of the problems of likening RDF 
> types to OO types):
> 
> [[
> The RDF Schema specification does not specify a specific vocabulary of 
> classes like Tent or Book, and properties like weightInKg or author. 
> Instead, it specifies the mechanisms needed to define such classes and 
> properties, and to control which classes and properties are used 
> together (for example, you probably wouldn't want the property jobTitle 
> to be used in the description of a Tent). In other words, the RDF Schema 
> mechanism provides a basic type system for use in RDF models.
> The RDF Schema type system is somewhat similar to the type systems of 
> object-oriented programming languages such as Java. For example, the RDF 
> Schema type system allows resources to be defined as instances of one or 
> more classes. In addition, it allows classes to be organized in a 
> hierarchical fashion; for example a class Dog might be defined as a 
> subclass of Mammal which is a subclass of Animal, meaning that any 
> resource which is in class Dog is also considered to be in class Animal.
> ]]
> 
> I'd suggest rewording this as:
> [[
> The RDF Schema specification does not specify a specific vocabulary of 
> classes like Tent or Book, and properties like weightInKg or author. 
> Instead, it specifies the mechanisms needed to define such classes and 
> properties, and to indicate how classes and properties are expected to 
> be used together (for example, the property jobTitle is typically used 
> in the description of a person).  In other words, the RDF Schema 
> mechanism provides a basic type system for use in RDF models.
> The RDF Schema type system shares some characteristics with the type 
> systems of object-oriented programming languages such as Java.  For 
> example, it allows resources to be described as instances of one or more 
> classes, and for classes to be organized in a hierarchical fashion.  A 
> class 'Dog' might be defined as a subclass of 'Mammal' which is a 
> subclass of 'Animal', meaning that any resource which is in class Dog is 
> also considered to be in class Animal.
> 
> However, RDF classes are in some respects very different from 
> programming language classes.  An RDF class is not a straitjacket into 
> which information must be forced, but is rather an annotation that 
> provides additional information about its instances.
> ]]


The current text generally follows the way these concepts were described 
in earlier versions of the Schema document (yet another consistency 
problem), but you raise an important point.  As your suggested text 
reads, though, it seems to me it goes too far in the other direction: 
making these definitions seem mostly advisory.  I'll see if I can work 
something out that's more in the middle.  One point that certainly needs 
to be made (that neither the suggested text nor what is there now seems 
to say explicitly) is that when you declare properties with certain 
domains and ranges, you are saying that if the properties appear, they 
ought to obey the specified domain and range declarations but that, 
unlike a typical OO programming language object, an instance might exist 
either *without* some of those properties (e.g., you can have a book 
without an author, even though author is declarated with a domain of 
book), or with *additional* properties (I can define a book with a 
"technical editor", even though I haven't defined such a property in the 
schema). [At least, I think this is right.]


> 
> I'd also suggest getting the idea of using the RDF language for writing 
> RDF schema stated up-front;  e.g. rewording:
> [[
> The RDF Schema specification uses the RDF data model itself to define 
> the RDF type system, by providing a set of pre-defined RDF resources and 
> properties that can be used to define user-specific classes and 
> properties. These pre-defined RDF Schema resources effectively define 
> the RDF Schema vocabulary, and become part of the RDF model of any 
> description that uses them. We will illustrate these basic resources and 
> properties in the following sections.
> ]]
> as:
> [[
> The RDF Schema specification maps the RDF type system into the RDF data 
> model, and thus uses the RDF language itself to describe new types and 
> properties.
> It introduces pre-defined RDF classes and properties for describing 
> relationships with user-specific classes and properties.  These 
> pre-defined RDF Schema resources underpin the RDF Schema vocabulary, and 
> become part of the RDF model of any description that uses them.
> ]]


I'm not sure I see a major difference between these wordings (?)


> 
> Section 4.2
> -----------
> 
> Again, there's very great emphasis on "constraints":
> [[
> RDF Schema also provides a mechanism for specifying simple constraints 
> on the use of properties and classes in RDF data. The basic constraints 
> are those that describe limitations on the types of values that are 
> valid for some property, or on the classes to which it makes sense to 
> assign such properties. Specifically:
> 
> A range constraint specifies that the value of a property should be a 
> resource of a designated class. For example, a range constraint applied 
> to the author property might specify that the value of an author 
> property must be a resource of class  Person.
> 
> A domain constraint specifies that a property may be used on resources 
> of a certain class. For example, a domain constraint applied to the 
> author property might specify that the author property could only 
> originate from a resource that was an instance of class Book.
> ]]
> I'd suggest trying to put more emphasis on "information":
> [[
> RDF Schema also provides a mechanism for specifying information about 
> the use of properties and classes in RDF data.  The basic information 
> indicates the classes of resources that are indicated by a property, or 
> on the classes to which properties are assigned. Specifically:
> 
> A range constraint specifies that the value of a property is an instance 
> of a designated class.  For example, a range annotation applied to the 
> author property might specify that the value of an author property is an 
> instance of class Person.
> 
> A domain constraint specifies the class of resource to which a properry 
> is applied. For example, a domain constraint applied to the author 
> property might specify that the resource to which the author property is 
> applied was an instance of class Book.
> ]]
> 
> Generally, I'd look to replace "constraints" with a more neutral term 
> like "attributes".


I understand your point, but (a) I do think they are constraints, 
they're just not as "constraining" as might appear on the surface, and 
(b) "attributes" might get confused with either XML attributes, or 
"properties".  We could just call them domain and range "specifications" (?)


> 
> Section 4.4
> -----------
> 
> Where you say "@@The above could clearly be developed a great deal 
> further!@@" I think you have said just about the right amount for a 
> document that is about RDF(s), and suggest you resist any temptation to 
> elaborate this section!


I'm willing.  Other opinions?


> 
> Section 5
> ---------
> 
> The RDF model theory does not currently mention rdf:Alt.  I think this 
> is a point of
> coordination to be resolved ... somewhere.
> 


Section 3.4 of the Syntax document has Alt as a reserved term, so 
there's another document where coordination needs to take place. 
***Anyone know the status of rdf:Alt?***

 


-- 
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 Monday, 29 April 2002 20:29:41 UTC