Re: WebID default serialization for WebID 2.x

Quoting Jacopo Scazzosi (2022-01-26 10:03:05)
> 
> > I feel something is getting lost in translation.
> 
> I have gone through quite a few message many times over and I feel the 
> same.
> 
> I understand that there’s a difference between a URI referencing a 
> document that describes a WebID and the WebID itself, which is where 
> the 303 and hash patterns come into play.
> 
> I think I grasp the conceptual difference betweeen denotation and 
> connotation and how it applies to data.
> 
> However, this doesn't change the fact that I still need to dereference 
> in order to learn about WebIDs, which in turn does reaffirm a 
> dependency on being able to parse at least the serialization formats 
> *required* by the spec and possibly one or more of the serialization 
> formats *suggested* by the spec. If the spec were to stop at merely 
> suggesting, without requiring, then clients would have to know how to 
> parse all possible RDF serialization formats in order to achieve max. 
> compatibility.

I suspect that you think like I did before August 14, 2021 at 20:34¹.

Yes, you need to dereference in order to learn about WebIDs.  But you 
need not always learn about WebIDs to use WebIDs.  Or you need not 
always learn about *all* WebIDs you use.

WebID specifies only that an URI *is* resolvable to an RDF graph, not 
*how* to resolve it.  That is decoupled into separate specs.

So the WebID spec only _promises_ that somehow it must be resolvable.

You can have a passport or a credit card and understand what it *is* 
without needing to know how issuing authorities validate it.

Border controls have a hotline to Interpol, to follow the specs of each 
country for how to validate citizen identity.  Expensive process, but is 
(arguably) needed to maintain World peace.

Hotels also use passports: They take a photocopy, trusting the *promise* that the passport is 
resolvable.  The protocols of hotel management does not involve 
"dereferencing the embedded graph knowledge" of passports.  Only if you 
leave without paying do they contact local authorities, hand them the 
photocopy, and _another_ protocol by local authorities includes (some 
places as a MUST but other places as a SHOULD) to call Interpol to 
resolve embedded knowledge graph.

HotelManagement spec depend only on PassportID spec, because it rely on 
the *promise* of resolvability: They choose to take the risk of fraud, 
because it is a) expensive to have a hotline to Interpol, and b) 
impractical to use such hotline every time (i.e. a MUST) - you might 
have noticed that queues at hotel front desks are often shorter than at 
border controls.

LocalPolice spec, however, depend on both PassportID spec and 
Passport-OurCountry and Passport-ForeignCountry specs.  LocalPolice 
might specify that Passport-OurCountry MUST be used but 
Passport-ForeignCountry SHOULD be used - because it is relatively cheap 
for local police to resolve knowledge about their own citizens than to 
call up Interpol and have them resolve knowledge of foreign citizens.

Do you really want - for the sake of interoperability - to *mandate* all 
handlers of passports to have Interpol hotlines installed - regardless 
if handlers' own protocols deliberately avoid using such hotline?

I argue that the result will be a semantic World where some innovation 
is outlawed - they still exist but use different identifiers, not 
because they want that but because we don't permit them to use our 
identifiers for their work: Less interoperability, not more!


 - Jonas

¹ See https://github.com/w3c/WebID/issues/3#issuecomment-898942543

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private