- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Mon, 24 Jul 2006 19:05:26 +0200
- To: "Xiaoshu Wang" <wangxiao@musc.edu>
- Cc: public-semweb-lifesci@w3.org, "Semantic Web" <semantic-web@w3.org>
On 7/24/06, Xiaoshu Wang <wangxiao@musc.edu> wrote: > >From my hasty look on the semantic-web, I think it is two different problem. > One concerns if we should describe what "kind" of a resources is. The other > seems worry about what kind of closure one should get. That sounds reasonable. I think we already have an example for a pattern for the former case, the foaf:PersonalProfileDocument. The detailed structure/content of the document isn't defined, the key part is that such a document has a foaf:primaryTopic which is a foaf:Person (I suspect the clause about the person being the maker of the document is less portable). > Using HTTP content negotiation to request different Closure of the RDF is > not appropriate. The Content negotiation is designed for data-format not > the closure specific to RDF. I agree that the typical current HTTP content negotiation setup would not be appropriate, being format-oriented. However I do think there may be potential for something analogeous to be useful. The worst of it is it will put a big burden on > the content provider. By that suggestion, an ontology won't be simply > placed on the web as an simple text RDF document. You must implement a lot > of server logic to do so, I don't think it will fly. Look at it from the opposite direction: there are situations where simply placing an RDF doc on the web will mean unnecessary burden, on the client and/or server. In such cases it may be useful to do a little preliminary negotiation to optimise what is served to the client's requirements. In a manner, this approach is already flying. An RDF store may contain billions of triples, but by using a query protocol (i.e. SPARQL) it's possible to deliver only the subset of interest to the client. This is less burdensome that directly serving a document containing the billions of triples. But it seems to me there should be less demanding approaches. If, for example, the client is only interested in say Geo data, that hint could be passed (somehow) in a HTTP header. For a server that recognised that header when an RDF-bearing URI was gotten, it would be possible to redirect the client to a more appropriate resource, such as one with a static file containing only Geo-related data. I certainly wouldn't imagine this as a mandatory behaviour, more like hints that could be ignored. Cheers, Danny. -- http://dannyayers.com
Received on Monday, 24 July 2006 17:05:39 UTC