W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2002

Re: comments on primer so far

From: Frank Manola <fmanola@mitre.org>
Date: Tue, 05 Nov 2002 08:55:03 -0500
Message-ID: <3DC7CDB7.8020102@mitre.org>
To: Brian McBride <bwm@hplb.hpl.hp.com>
CC: RDF Core <w3c-rdfcore-wg@w3.org>

Brian McBride wrote:

> 
> At 21:24 04/11/2002 -0500, Frank Manola wrote:
> 
>> Brian--
>>
>>
>> Some comments on your comments (I'm not going to comment on all of 
>> them,  just the ones where I either question the call, would like some 
>> more input, or otherwise feel like wrangling about):
>>
>> Section 1:
>> [[If you were to allow me one silver bullet, one stylistic change you 
>> made just because I asked for it, it would be this one(he says not 
>> having read the rest of the document yet.) The first time a reader 
>> sees RDF they should see a graph, not RDF/XML. For me, it is very 
>> important to get the reader thinking about graphs, not XML, right from 
>> the get go.]] (Brian's comments are deliminted by [[ ]]  )
>>
>> I understand your point.  The problem is that we've just got through 
>> talking about how useful RDF is for expressing information so it can 
>> be exchanged between applications, and so on.  While the 
>> model/abstract syntax is a graph, the only way the graph can be 
>> exchanged between applications is to write them down, and the 
>> normative syntax for doing that is RDF/XML.  I really do understand 
>> that the graph is the "essence"  of RDF;  but it seems to me that at 
>> this point (where we say we're going to be "concrete"), we want to 
>> show folks how they're actually going to be writing stuff down.
> 
> 
> In general, I won't argue about sytlistic changes.  They are suggestions 
> to the editor, no more.  This is the exception, because I do think its 
> important.
> 
> My concern is that folks coming to RDF who are familiar with XML, and I 
> have seen this happen too often, approach it with an "XML mindset".  Dan 
> and I are arguing that we shouldn't be teach xml in this doc and should 
> assume folks are already familiar with it, i.e. these folks are our 
> intended audience.
> 
> I believe it is absolute vital, to tell them right from the start what 
> the conceptual model is, otherwise they think its just same old xml and 
> we will lose to many of them.
> 
> I take your point about not writing exchanging information between 
> applications.  I think we could write our way out of that one.  We could 
> change the preceding text, and for me, it be worth the effort, but then 
> its your effort.  Or we could just delete this bit.  I know Dan is keen 
> on having it so early on, but this is my opinion. However, I don't think 
> we have to go that far.  We can write our way round it.
> 
> [[
> To make the discussion concrete as soon as possible, let's look at some 
> RDF.  The best way to think about RDF is as a graph.
> 
>   picture here.
> 
> This is a description of a person ...
> 
> The graph is the conceptual model for RDF.  Now lets look at he write it 
> down as XML.
> 
>   ...
> 
> ]]
> [...]


Yes, this will work.  I just replied to Dan that we could talk about the 
graph, and illustrate the XML example (without saying too much about it) 
at that point.


> 
>> [[This section on URI's seems like a big barrier to the reader early 
>> on. I'd expect a primer to introduce stuff more gradually. In style, 
>> this is beginning to feel more like a text book than a primer]]
> 
> 
> 
> [..]
> 
> 
>> [["Bedford" is not the city, its the name of the city. Similarly for 
>> state. Suggest rename properties to cityName, and stateName. Not sure 
>> what to rename street to.]]
>>
>> I'm commenting on this because it's listed as an "error".  If I gave a 
>> URI for the city instead of the literal "Bedford", that wouldn't be 
>> the city either, that's another name for the city.  Would you have me 
>> say "cityName" then too?  "cityURI"?  I understand the distinction 
>> you're making, but I really am trying to indicate the city;  the only 
>> way I can do that is by using a name.
> 
> 
> I'm suggesting changing the property name to indicate the sort of thing 
> the object is, not the sort of thing the name of the object is.  We are 
> in the domain here, not the syntax.


I know you are.  But that's the way people talk.  (We also would say 
"age", rather than "ageNumeral" wouldn't we?).  Obviously we need to 
make these distinctions, but it seems to me we want to make them by 
defining the appropriate property ranges, rather than diddling with the 
names (?)


> 
> 
>> [[Thinking about it, do we really need to keep giving triples 
>> representations for everything. Won't the picture of the graph suffice?]]
> 
> 
> [...]
> 
> 
> 
>> "and RDF would not see anything wrong with this." [[No, strongly 
>> disagree. We are talking about what an RDF procesor would do here, and 
>> an RDF processor that is datatype aware would barf. We need to 
>> describe the different behaviour to expect between software that 
>> understands the datatype and software that does not.]]
>>
>> What I was talking about was what was visible to *RDF*, and *RDF* 
>> knows nothing about any datatypes, as far as I know.
> 
> 
> I think that will mislead the reader.  I thought you were talking about 
> an rdf processor.  This is a primer; its about teaching folks how to do 
> stuff right?  We need to keep it accurate regarding the formal stuff, 
> but we also need to keep in mind the readers mindset.
> 


As I said, I agree we need to make the distinction between what RDF 
"knows" and what a "datatype-aware" processor "knows".  This may also be 
the place to make the point about XML Schema data types being "first 
among equals".  That is, something like:

a.  RDF per se doesn't build in datatypes
b.  RDF *processors*, on the other hand, are likely to have certain 
collections of datatypes that they "understand", and would recognize 
inconsistencies for
c.  One collection that's extremely likely to be built into such 
processors is the XML Schema datatypes (or at least some of them).
d.  Users need to be aware of which datatypes their processors are 
prepared to directly handle in this way.


--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 Tuesday, 5 November 2002 08:38:43 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:53:58 EDT