- From: Adrian Walker <adrianw@snet.net>
- Date: Wed, 18 Feb 2004 12:46:28 -0500
- To: "Thomas B. Passin" <tpassin@comcast.net>
- Cc: www-rdf-interest@w3.org
Thomas Passin wrote... "... [Locally-Significant Statements] is a worthy problem, but it is not unique to RDF. It is really a data modeling problem, and the best solution will depend on what you want to achieve by your modeling. You would have the same set of issues - pretty much - if you were designing a relational database." Agreed, it's not unique to RDF, but it is perhaps particularly problematic in RDF. We should remind ourselves once a week that RDF is designed for _machines_ to communicate with one another. Not for people to communicate with machines. Not for machines to communicate with people. There arises the question of how machines trading with one another in RDF will in future communicate with nontechnical _people_ who bear responsibility for setting up, understanding and approving the machine transactions. You really don't want your semantic web agent to sell all your stock in the Cheerios manufacturer and invest in Enron because it has aggregated some nice RDF from five different servers. Showing you the aggregated RDF before it does this will not help you much, because of the ambiguities about the local contexts for "price", "cost" and so forth. Anyway, RDF was not designed for human readability. Admittedly it's early days, but it may be a good idea to address this question of RDF-Person communication sooner rather than later. One possible approach is described in the "Semantic Web Presentation" at the site listed below. Are there other approaches ? If so, they should hopefully be of rdf-interest. Cheers, -- Adrian INTERNET BUSINESS LOGIC www.reengineeringllc.com Dr. Adrian Walker Reengineering LLC PO Box 1412 Bristol CT 06011-1412 USA Phone: USA 860 583 9677 Cell: USA 860 830 2085 Fax: USA 860 314 1029 At 09:31 AM 2/18/04 -0500, you wrote: >Rhoads, Stephen wrote: >>I would appreciate some guidance as to the best approach to the problem of >>what I will call (for lack of a better term) making locally significant >>statements about a resource. I have identified three approaches which I am >>calling "Wrapper", "InstanceOf", and "Context". >>Take the example below. General Mills manufactures an ex:Cereal called >>Cheerios which is distributed by Whole Foods, Publix and Fresh Direct. >>General Mills has assigned the URI >>"http://www.generalmills.com/cereal/Cheerios" to Cheerios which is then used >>by Whole Foods, Publix and Fresh Direct as the subject of statements which >>report price, inventory number and availability. > ... > >This is a worthy problem, but it is not unique to RDF. It is really a >data modeling problem, and the best solution will depend on what you want >to achieve by your modeling. You would have the same set of issues - >pretty much - if you were designing a relational database. > >Seems it me that a retailer sells a product, while a wholesaler >distributes products. A manufacturer also distributes products, acting as >a wholesaler (it may act as a retailer, too). > >So we know that > >1) A Manufacturer makes products. >2) A Manufacturer distributes products to wholesalers in lots. >3) A Wholesaler distributes products to retailers in lots. >4) A Wholesaler stocks products. >5) A Retailer stocks products. >6) A Retailer sells products individually. > >These would be the building blocks for the data model. Now you have >typical modeling questions to decide on, like > >a) Should there be a productLot entity? >b) Is an individual product instance sold by a retailer different from the >generic "product" made by the manufacturer - i.e., is the manufacturer's >product essentially a model number for the purposes of this data model? >c) Do you have to track lot numbers at the retail level,in case of a >product recall? >d) What is the relation between a product lot, an individual product >instance, and the manufacturer's product designation? > >The answers to these questions will depend on what you want to accomplish >or express with the data model. Notice that RDF is not involved >here. Only when you have the data model under control is it time to >translate to RDF. In fact, if you create a relational database model, you >can then pick apart the tables and turn them into triples - that gives you >your schema, basically. > >Notice that this process arrives at certain specialized data >structures. They will be properly understood only by a processor that is >prepared to recognize them and work with them appropriately. A general >purpose processor will probably not be able to do this, or at least not as >effectively and quickly as a special-purpose one. > >Such data structures form a kind of idiom, and I think that we will see a >great many idioms in the future, as RDF gets deployed more widely. > >Cheers, > >Tom P
Received on Wednesday, 18 February 2004 12:42:52 UTC