- From: Alexandre Passant <alexandre.passant@deri.org>
- Date: Wed, 19 Aug 2009 12:38:56 +0100
- To: Ivan Herman <ivan@w3.org>
- Cc: Axel Polleres <axel.polleres@deri.org>, "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Hi, On 19 Aug 2009, at 08:44, Ivan Herman wrote: > > > Axel Polleres wrote: >> As a lightweight version of Option 7, which reuires content >> negotiation >> to receive the RDF service description on the endpoint URL, there >> occurred some sub-options in the discussion today, which I try to >> summarize below: >> >> Option 7' (RDFa): If HTML is served instead of RDF at the endpoint >> location (e.g. a query form), then allow it to have implicitly the >> RDF >> of the service description in the form of RDFa >> >> con: RDFa needs to be parsed/extracted to get RDF out >> > > I think what this means is, for most cases, another request in > practice, > which makes raises the same problem as Option 7''. Indeed, for a user > the simplest way of extracting the RDF from RDFa would be to run the > HTML content through some RDFa extractor service (like RDFa > Distiller[1]). Actually, I think we may assume that in a near future SPARQL engine / RDF APIs will directly allow to run SPARQL queries on RDFa pages (that is what rapper already does), so that wouldn't be a major issue. While I'm really willing to see RDFa annotated endpoints, I think that 2 issues in that case would be: - Some endpoints do not provide any forms for query input (unless we want to say in the next spec that any endpoint must have a form for query input - I'd favor that as well) - It implies that the form uses XHTML - since RDFa in HTML5 is currently unclear (maybe someone closer to that issue can tell what's the current and expected status of [1]) In any case, if not the only option, I'd be happy to see that solution mentioned in the service description document. Best, Alex. [1] http://dev.w3.org/html5/rdfa/rdfa-module.html > > I must admit I begin to wonder whether this is indeed such a strong > issue, though. One more (cashable request)... Is it really a show- > stopper? > >> Option 7'' (LINK element) >> If HTML is served instead of RDF at the endpoint location (e.g. a >> query >> form), then allow it to have a <link> element in the HTML head >> pointing >> to the service description >> >> con: needs 2 requests (which originally was the strongest argument >> against Option 1) >> >> Option 7''': either of Option 7'/7'' in combination with the pure >> Option >> 7, i.e. if content type HTML is requested, require anyways Option >> 7' or >> 7'', when content type RDF is requested, serve description directly. >> > > I think that would require to give a more precise definition of what > the > URI returns in the case of HTML, in order to make conneg acceptable in > term of HTTP usage. Ie, write down the common practice of having a > request form, and also require to write down the content of the > service > description in proper English or other language (which, I believe, > would > be a good practice anyway). On the other hand, this option could also > work if the client does not have the right authority (or knowledge!) > to > set up conneg on the server side... > > Ivan > >> Axel >> >> >> > > [1] http://www.w3.org/2007/08/pyRdfa/ > > > -- > > Ivan Herman, W3C Semantic Web Activity Lead > Home: http://www.w3.org/People/Ivan/ > mobile: +31-641044153 > PGP Key: http://www.ivan-herman.net/pgpkey.html > FOAF: http://www.ivan-herman.net/foaf.rdf -- Dr. Alexandre Passant Digital Enterprise Research Institute National University of Ireland, Galway :me owl:sameAs <http://apassant.net/alex> .
Received on Wednesday, 19 August 2009 11:39:43 UTC