- From: Frank Manola <fmanola@mitre.org>
- Date: Thu, 19 Jul 2001 17:07:21 -0400
- To: Brian McBride <bwm@hplb.hpl.hp.com>
- CC: rdf core <w3c-rdfcore-wg@w3.org>
Here's some more on the anonymous nodes discussion, helped considerably by Brian's translation of his original examples [thanks!]. so here are Brian's examples, with his translation: > #advert123 :role "buyer"; > :description [:product :roses; > :quantity [:units :kg; :minValue "100"]]. > > translates to: > > <#advert123> <foo:role> "buyer" . > <#advert123> <foo:description> _:service . > _:service <foo:product> <foo:roses> . > _:service <foo:quantity> _:q . > _:q <foo:units> <foo:kg> . > _:q <foo:minValue> "100" . > > i.e this is advert placed by a purchaser who wishes to buy roses in > minimum quantities of 100. > > and > > #advert456 :role "seller"; > :description [:product :roses; > :quantity [:units :kg; :maxValue "500"]]. > > translates to: > > <#advert456> <foo:role> "seller" . > <#advert123> <foo:description> _:service . > _:service <foo:produce> <foo:roses> . > _:service <foo:quantity> _:q . > _:q <foo:units> <foo:kg> . > _:q <foo:maxValue> "500" . > > i.e. this is an advert placed by a seller who can sell roses in > quantities upto 500. > Neither is a specific service. The "buyer" advert is essentially a template. > The seller is offering the existence of at least one service that matches a > template - he may have many actual instances on offer which differ by location, qos > etc. > Here is an offer of specific service: > > #offer890 :inResponseTo #advert123; > :instanceOf #advert456; > :service #service42 > > #service42 :product :roses; > :quantity [:units :kg; :value "200"]]; > :deliveryTime [:units :days; :value "2"]; > :deliveryMethod "TNT"; > etc > . I've translated this to: <#offer890> <foo:inResponseTo> <#advert123> <#offer890> <foo:instanceOf> <#advert456> <#offer890> <foo:service> <#service42> <#service42> <foo:product> <foo:roses> <#service42> <foo:quantity> _:q . _:q <foo:units> <foo:kg> _:q <foo:value> "200" <#service42> <foo:deliveryTime _:t . _:t <foo:units> <foo:days> _:t <foo:value> "2" <#service42> <foo:deliveryMethod "TNT" etc. Brian says: > Now. If we don't have anonymous nodes then we have the following problems. > > (1) In the seller advert it would appear that the seller is only advertising > a single specific (but under-specified) service, #anon12345 or whatever, which > would be hard to distinguish from an actual service instance like #service42. > > (2) Similarly in the buyer advert instead of describing a template, giving > the service a URI would make it appear that I am looking for a specific service > with that URI. It seems to me that what's going on is this: There is a distinction in RDF between anonymous resources and those with URIs, and Brian's folks use that as a coding scheme for distinguishing references to templates from references to specific things. However, I don't think there there is any built-in support for this specific interpretation in RDF. So, while I suppose people could use that coding scheme, they wouldn't be wise to assume that everyone else was using URIs and anonymous resources to make the same distinctions. It seems to me that the distinction in RDF is mostly "syntactic" in a sense; that is, anonymous nodes are provided as a way to, in certain cases, avoid the need to explicitly specify a URI in the RDF. It doesn't necessarily mean that there wasn't one that couldn't have been provided. The original "Ora Lassila" example wasn't really describing the creator of the home page as a template which matched any of a number of people who happened to be named "Ora Lassila" and had a specified email address (they might have meant that, and in fact a given description may actually match several people, but I claim that wasn't the intent here). The writer of the RDF was referring to a specific person. The immediately following example in the M&S showed how, if a URI for Ora Lassila existed (and if you wanted to provide it), you could do so without using an anonymous resource. Looking at this the other way, it seems to me that the specific offer in Brian's example could just as easily have been expressed using an anonymous resource, e.g.: #offer890 :inResponseTo #advert123; :instanceOf #advert456; :description [:product :roses; :quantity [:units :kg; :value "200"]]; :deliveryTime [:units :days; :value "2"]; :deliveryMethod "TNT"; etc ] which translated is: <#offer890> <foo:inResponseTo> <#advert123> <#offer890> <foo:instanceOf> <#advert456> <#offer890> <foo:service> _:service _:service <foo:product> <foo:roses> _:service <foo:quantity> _:q . _:q <foo:units> <foo:kg> _:q <foo:value> "200" _:service <foo:deliveryTime _:t . _:t <foo:units> <foo:days> _:t <foo:value> "2" _:service <foo:deliveryMethod "TNT" etc. This conveys exactly the same information, with the exception of an explicit URI for the service. But the buyer doesn't really need to know the URI of the service; all he needs to do is reply with an "accept" to the specific offer, and the seller would understand exactly which service was meant. The point is that the offerer in this case might reply with an anonymous node for the service, but still be referring to (or at least, able to provide) a specific service. Conversely, when you have a specific URI, you know that it is the unique identifier that someone has assigned to identify something, but you don't necessarily know what kind of a "something" that is. For example, your advert placed by a seller who can sell roses in quantities upto 500 could just as easily been expressed in RDF using a specific URI, as: #advert456 :role "seller" ; :description #service456 #service456 :product :roses; :quantity [:units :kg; :maxValue "500"]]. which translates to: <#advert456> <foo:role> "seller" . <#advert123> <foo:description> <#service456> . <#service456> <foo:product> <foo:roses> . <#service456> <foo:quantity> _:q . _:q <foo:units> <foo:kg> . _:q <foo:maxValue> "500" . The seller in this case has chosen to identify a *service description* with a URI, but that's perfectly OK as far as RDF is concerned (a URI can denote anything), and in a given application that might be a perfectly sensible thing to do. The seller might also have specific services with their own URIs. Each kind of resource (service offers and services) could be defined (say in RDFS) as being of different classes (so you'd tell them apart by class, not by whether they were URIs vs. anonymous). Seller applications dealing with services and service offers would know how to deal with the differences appropriately; and buyers might not have to worry about it, if the service identities didn't need to be exported. Even if they did, it seems to me that, in general, we'd do well to determine what kind of thing was represented by a URI (or other identifier) on the basis of explicit metadata (e.g., in RDFS class definitions), rather than on the basis of anonymous resource vs. URI (after all, there are lots more distinctions than "specific resource" vs. "variable" that we have to be able to make). The bottom line here is that while anonymous nodes can certainly be used (at least in some cases) to make the distinction Brian's example illustrates, I don't think it's *necessary* for that purpose, and they aren't necessarily going to be used uniformly by everybody to make those sorts of distinctions. (In fact, I'm not terribly confident about how general a mechanism anonymous resources are for defining template-like things; I think if we want variable and template support, we probably should look at this explicitly and more exhaustively, rather than assuming that anonymous resources provide what we need for this). --Frank PS: note also that the _q anonymous resource is used in both "templates" and specific service offers, and is interpreted the same way in each case (what's different isn't the use of _q to indicate an anonymous quantity resource, but the distinction between precise values <foo:value> and constraints on values <foo:maxValue>). -- 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-8752
Received on Thursday, 19 July 2001 17:12:27 UTC