please proofread episode 10

[michielbdejong]

proofreaders welcome! :)

https://unhosted.org/adventures/10/Linking-things-together-on-the-world-wide-web.html

scheduled for release on Tuesday

[michielbdejong]

cc particularly @melvincarvalho btw! :) very interested in your feedback before publishing it, if possible.

[melvincarvalho]

On 15 February 2013 17:40, Michiel@unhosted notifications@github.comwrote:

proofreaders welcome! :)

https://unhosted.org/adventures/10/Linking-things-together-on-the-world-wide-web.html

Looks like an interesting post. I think it's a great how you try to explain URLs and URIs as pointers to data (in particular, that you can add key/value pairs to these pointers). They are really the building blocks of the past and future of the web. It's hard stuff and a paradigm shift of thinking for many (at least it was for me). But mastering this stuff can really unleash much more power on the web. Let me digest some of the detail and get back ...

scheduled for release on Tuesday

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/35.

[melvincarvalho]

On 15 February 2013 17:40, Michiel@unhosted notifications@github.comwrote:

proofreaders welcome! :)

https://unhosted.org/adventures/10/Linking-things-together-on-the-world-wide-web.html

Just going through sequentially:

'First, each data record, or in web terms each document, refers to other records using pointers that live in the untyped global namespace of URLs, and that may or may not work.'

what do you mean by untyped, altho uris dont have a type such as Int, String etc. you can perform introspection on the URI to find out the scheme/protocol which will then tell you what sort of identifer it is, e.g. http, mailto: xmpp: urn: etc.

scheduled for release on Tuesday

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/35.

[melvincarvalho]

On 15 February 2013 17:40, Michiel@unhosted notifications@github.comwrote:

proofreaders welcome! :)

https://unhosted.org/adventures/10/Linking-things-together-on-the-world-wide-web.html

"Second, the data is not enumerable. You can enumerate the data that is reachable by following links from one specific document, but you can never retrieve an exhaustive list of all the web's content."

So this is the key to the whole thing. The web is a graph rather than a tree. This makes everyone an equal, rather than, having a hierarchy with masters and slaves. If there was one great side effect for humanity from this topology, that's the one. Almost every other system before and after was a tree, think AOL, Gopher and even structure you see in society. This was the most brilliant gift given to us, id put it up there with newtons laws and the invention of the PC itself (which actually was invented by tims dad!).

scheduled for release on Tuesday

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/35.

[melvincarvalho]

On 15 February 2013 17:40, Michiel@unhosted notifications@github.comwrote:

proofreaders welcome! :)

https://unhosted.org/adventures/10/Linking-things-together-on-the-world-wide-web.html

scheduled for release on Tuesday

"As we said earlier, the web started as a collection of hypertext documents, and evolved from there into the "html5" app platform we know today. But very early on, the potential of using the web for not only human-readable but also machine-readable data was discovered."

Sort of. The web of data was the idea from the start. The end goal of the web is to allow 'everything connected to everything'. Documents were just a bootstrap so that tim could get his work adopted in a wider community. You might even say it is the lesser, or less exciting, use case of the web. Nevertheless it's done pretty well so far!

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/35.

[melvincarvalho]

On 15 February 2013 17:40, Michiel@unhosted notifications@github.comwrote:

proofreaders welcome! :)

https://unhosted.org/adventures/10/Linking-things-together-on-the-world-wide-web.html

scheduled for release on Tuesday

"Many good data formats actually contain this requirement. For instance, many of the data formats that our remoteStorage modules use contain an '@type' field that points to a documentation URL."

JSON LD uses @context, you may want to use that instead so that the same software can support LD and remoteStorage. By aligning terms we can build a bigger ecosystem with more developers and the network effect that goes along with it. It's not a must the alternative is to run two sets of software the polyglot approach, but convergence is normally beneficial.

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/35.

[michielbdejong]

introspection on the URI to find out the scheme/protocol which will then tell you what sort of identifer it is, e.g. http, mailto: xmpp: urn: etc.

right, i was thinking only http there, since i'm making the analogy of database records, and a mailto: URI doesn't represent a retrievable data record.

Almost every other system before and after was a tree

yes, good point i will add a paragraph that highlights that point.

Documents were just a bootstrap

i'm not sure if there's enough retrospective evidence to make such a claim stronger than the one i'm already making, and i'm also not sure if it would help. in practice, what we call "the web" has a very big human-readable component; regardless of whether its inventor regards that as a side-effect of the machine-readable part, i feel it's more accurate about how people use the term web in practice. but still, interesting point!

JSON LD uses @context

oh, are we doing that wrong? thanks for the heads-up, i'll have a look at that.

[melvincarvalho]

On 15 February 2013 17:40, Michiel@unhosted notifications@github.comwrote:

proofreaders welcome! :)

https://unhosted.org/adventures/10/Linking-things-together-on-the-world-wide-web.html

"There is a school in web architecture (I always half-jokingly call it the "URI purism" school), which states that whenever you use a URL as a URI (i.e., to denote a concept), then you may not call it a URL (you have to call it either URI or URN), and it should either have a hash ('#') in it, or\ respond with a 303 status code. I don't see the point of this; everybody outside of URI purism just uses URLs without these imho random complications, which is a lot simpler and works fine, too."

Extremely difficult and misunderstood subject which contains elements of syntax, semantics, metaphysics and aesthetics. I cant say I know everything on this topic, but here's what I understand. But it's also an important topic.

1. A URI is the umbrella term for a URN (name) or URL (locator)
2. Any URI can be a locator if you can follow your nose to get more data.

3a. In the world of HTTP we can assign key value pairs to URLs using @property.

3b. You can assign key value pairs to the document itself, e.g. licence etc.

3c. You can assign key value pairs to data points inside the document, which are generally denoted with a #.

I did not grok this for a long time. The way I worked it out was to consider the 7000 year history of documents and to ask myself whether splitting documents into sections was a good design choice and I came up with the answer yes. So that means you can have multiple data points in a document, to very often one document and one data point represent a kind of best practice (consider the analogy with java classes or JSON files).

@webr3 may be able to explain better ...

scheduled for release on Tuesday

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/35.

[melvincarvalho]

On 16 February 2013 16:59, Michiel@unhosted notifications@github.comwrote:

introspection on the URI to find out the scheme/protocol which will then tell you what sort of identifer it is, e.g. http, mailto: xmpp: urn: etc.

right, i was thinking only http there, since i'm making the analogy of database records, and a mailto: URI doesn't represent a retrievable data record.

So yes the pointers are untyped strings, but when you dereference them (HTTP GET) you can get key/value pairs, one of which can be a rdfs : type which tells you what it is. This is quite similar to dereferencing in languages such as C. Just that the web core dumps less often :P

Almost every other system before and after was a tree

yes, good point i will add a paragraph that highlights that point.

Documents were just a bootstrap

i'm not sure if there's enough retrospective evidence to make such a claim stronger than the one i'm already making, and i'm also not sure if it would help. in practice, what we call "the web" has a very big human-readable component; regardless of whether its inventor regards that as a side-effect of the machine-readable part, i feel it's more accurate about how people use the term web in practice. but still, interesting point!

It's the sense I got from reading tim's book and notes. The take away is that we're really just at the very beginning of the journey that is the web. Small groups of people working together can really make a difference. The vision of the web is humanity connected via technology.

JSON LD uses @context https://github.com/context

oh, are we doing that wrong? thanks for the heads-up, i'll have a look at that.

There's not really a right or wrong. More a case that existing libraries can work with the same data stores as easily as possible. The normal arguments for reuse etc. Hopefully all these efforts will converge into one ecosystem in the medium term...

— Reply to this email directly or view it on GitHubhttps://github.com/unhosted/website/issues/35#issuecomment-13654627.

[michielbdejong]

published.

https://unhosted.org/adventures/10/Linking-things-together-on-the-world-wide-web.html

thanks a lot! :)