Re: discovering an authority endpoint

On 11/20/14 12:10 AM, Manu Sporny wrote:
> On 11/19/2014 07:08 PM, Kingsley Idehen wrote:
>>> The benefit of this approach is that you can embed the services in
>>> the HTML document as JSON-LD or RDFa, or you can content negotiate
>>> for it. You also don't have to have special .well-known URL
>>> registries and the solution can be re-used for any sort of REST
>>> API web services on the site (and extended dynamically instead of
>>> having to go through IETF or W3C).
>> Re. HTML are you going to use <link/> and @rel in <head/> to expose
>> key relations?
> I think it's a good idea. I'm not sure most Web developers will do it.

What's difficult here? This is all about using existing HTML 
elements/tags to express relations. The most basic relation, which 
bootstrapped the blogosphere and Web 2.0 was:

<link rel="alternate" href="{some-rss-feed-url}" ... /> .

More recently we've seen the rise of:

<link rel="related" href="{some-related-web-resource-url}" ... /> .


<link rel="canonical" href="{web-resource-permalink}" ... /> .
>
> Why not just content negotiate for the root document instead of having
> all those link @rels in HEAD? Wouldn't that be simpler?

No, since these "Web Developers" don't seem to want or be able to 
configure HTTP servers. In some cases, they don't even have requisite 
privileges on these servers.

<link/> provides similar document type selection capability to HTML 
oriented user agents.

My point it that you end up with targeting a broader audience when you 
incorporate <link/> (HTML processors), <script/> (HTML processors that 
sniff out data islands e.g., most JSON-LD processors, and "Link:" (for 
HTTP level processors).

Rather than deem anything as being "too difficult" why not provide 
options? The more the merrier.

>
>> With <script/> based structured data islands an additional mechanism
>> for relations discovery?
> This seemed to be the most likely thing that Web developers would do.

Again, we don't know what some other group of cognitive beings will do, 
so rather than predict (imprecisely) why not provide options? These 
cognitive beings are eternally whimsical -- something computer 
technology continuously forgets or overlooks.

>   So
> if we had to pick one thing, I think this should be it.

You don't pick one thing and attempt to mandate it to others, via a 
spec. That never works. Look at what it did to RDF, for instance.

>   It's worked out
> quite well for schema.org markup and the Actions stuff in Gmail for JSON-LD.

That's isn't the World Wide Web. I believe this endeavor is about the 
Web rather than the whims of specific organizations and/or individuals.

>
>> In addition to the above you can create HTTP renditions of all the
>> <link/> and @rel based relations via "Link:".
> Yes, also a good idea, but I don't think we have a good track record of
> getting Web developers to do that.

Again, let's not speak for the so called "Web Developer" . That will 
never work. Instead, provide options the reduce reasons for not making 
resources discoverable to agents etc...

Do not split the baby, it will never survive :)


>
> -- manu
>


-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this