Re: "suboptions" of Option 7

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