Re: Important Question re. WebID Verifiers & Linked Data

On 12/22/11 11:05 AM, Mo McRoberts wrote:
> On 22 Dec 2011, at 15:42, Kingsley Idehen wrote:
>
>> On 12/22/11 9:57 AM, Patrick Logan wrote:
>>> OK, that seems manageable, assuming it all specs out.
>>>
>>> So looking at the 12 December 2012 draft (
>>> http://www.w3.org/2005/Incubator/webid/spec/#in-portable-contacts-format-using-grddl
>>> ), it looks like (2) RDFa and (4) RDF/XML are in the draft, but (1)
>>> HTML+Microdata and (3) Turtle are not.
>>>
>>> In particular the two most relevant sections look to be:
>>>
>>> ========
>>> 3.2.4.1 Processing the WebID Profile
>>>
>>> The Verification Agent must be able to process documents in RDF/XML
>>> [RDF-SYNTAX-GRAMMAR] and RDFa in XHTML [XHTML-RDFA]. The result of
>>> this processing should be a graph of RDF relations that is queryable,
>>> as explained in the next section.
>>> ========
>>>
>>> How should that read instead?
>> ========
>> 3.2.4.1 Processing the WebID Profile
>>
>> The Verification Agent SHOULD be able to process at least one of the following structured documents types: RDF/XML
>> [RDF-SYNTAX-GRAMMAR], RDFa in XHTML [XHTML-RDFA] or HTML, Turtle, and Microdata in HTML. The result of
>> this processing should be a graph of RDF relations that is queryable,
>> as explained in the next section.
>> ========
>
> It needs to be tighter than that. If there is to be support for multiple formats (and IMO there should be), the flexibility needs to happen on the publisher side, not the consumer side — otherwise you end up with the situation where people publish things perfectly conformantly and they can't be processed by consumers which are equally conformant. WebID is useless if it only works some of the time.

Yes, great point! We clearly need to isolate the publisher of Linked 
Data and the consumer of Linked Data.

Linked Data Publisher Responsibilities:

1. support de-referencable URIs
2. support basic content negotiation -- basically a case of indicating 
to user agents what formats you support for resources associated with a 
given URL when user agent requests contradict what you are able to serve 
up .


Linked Data Consumer Responsibilities:

1. de-reference URIs
2. negotiate resource representation
3. leverage resource discovery patterns like <link/> relations in 
<head/> if the server doesn't honor content negotiation and sends back 
HTML -- the most common pattern .


>
> Assuming Microdata is baked in:—
>
> ========
> 3.2.4.1 Processing the WebID Profile
>
> The Verification Agent MUST be able to process the following structured document types:
>
> * RDF/XML [RDF-SYNTAX-GRAMMAR]
> * RDFa in XHTML [XHTML-RDFA]
> * Microdata in HTML [HTML5]

Turtle is missing from the list. Contemporary Linked Data tools prefer 
Turtle over RDF/XML. By this I mean: there are far more tools today that 
process Turtle than there are those that process RDF/XML.

>
> A Verification Agent MAY also support the processing of other structured document types.
> ========
>
> ========
> 2.2 Publishing the WebID Profile Document
>
> The protocol does not depend on any particular serialisation of the graph, provided that agents are able to parse that serialisation and obtain the graph automatically. Technologies such as GRDDL [GRDDL-PRIMER] for example permit any XML format to be transformed automatically to a graph of relations. Yet for reasons of interoperability is has been decided that the document must be published at least in one of RDFa [XHTML-RDFA], RDF/XML [RDF-SYNTAX-GRAMMAR], or Microdata in HTML [HTML5]. HTTP Content Negotiation [SWBP-VOCAB-PUB] can be employed to aid in publication and discovery of multiple distinct serialisations of the same graph at the same URL. A WebID Profile Document MAY also be published in other formats, provided it can be retrieved by resolving the WebID URI.
> ========
>
> Similarly, there needs to be working somewhere which makes HTTP and HTTPS a MUST with other schemes a MAY, but reading the spec I couldn't figure out entirely where to insert it -- I think the first couple of paras of §2.1 may need rewording to make clear the relationship between the SAN URI and the document.

URI abstraction is scheme agnostic. HTTP should be a suggestion. In 
reality, nobody is going to make an HTTP alternative as part of their 
WebID implementation. At the same time, implementers will support other 
schemes and bridge to HTTP. A mailto: or acct: scheme URI will always be 
a more intuitive WebID than an http: scheme URI.

>
> There should also be a note, somewhere near the top, to the effect that future versions of the specification will very likely revise which types of structured document and which protocols are a MUST and which aren’t. This is 1.0. You should be able to know that a WebID 1.0 VA can handle RDF/XML, RDFa and Microdata for definite, and — for example — that if you want to only bothering to publish Turtle, your WebID will only work with WebID 1.1 VAs (for example).

Turtle has to be there right now. Keeping it out is also kinda 
contradictory. Remember, SPARQL query patterns used in WebID examples 
are based on Turtle. Without Turtle we wouldn't have SPARQL. Without 
SPARQL (albeit an implementation detail) you wouldn't have the 
exponentially growing Linked Open Data Cloud of today.


>
> M.
>


-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen