Re: Toward easier RDF: a proposal

In your slides, David, you mentioned jargon as a problem, and as a relative
newbie to RDF I'd agree. It's drastic I realize, but if everything is on
the table I may as well make the suggestion. It might be easier for
complete newbies if plainer language was used:

   - Resource -> Thing
   - Predicate/property -> Relation

Then a statement would be:

Thing–Relation–Thing


I understand the heritage behind the current naming, but for a newbie the
first hurdle is understanding that "resource" has a different meaning to
the one in the dictionary, that it actually means "thing". The dictionary
definitions of "predicate" and "property" also don't correspond to the
center position of an RDF triple in my opinion, whereas the dictionary
definition of "relation" does.

Consequences would be RDF becomes TDF, or simply DF, to avoid redundancy.
URI unfortunately becomes UTI, though it could be shortened in a similar
way to simply UI.

I know it likely won't be a popular idea, but if you're looking for the
perspective of relative newbies that's one about jargon I can share.

Anthony

On Mon, Dec 17, 2018 at 12:29 AM Ruben Verborgh (UGent-imec) <
Ruben.Verborgh@ugent.be> wrote:

> Hi David,
>
> >> – build powerful query engines such that app developers do not need to
> write HTTP requests >   (every data access should be a query, read or write)
> >
> > Can you please elaborate a bit on this one, perhaps with an example? I'm
> wondering what kinds of query engines you envision, and how to use them.
>
> The usage of such query engines is best illustrated here:
>
> https://ruben.verborgh.org/blog/2017/12/20/paradigm-shifts-for-the-decentralized-web/#interfaces-become-queries-p-5
>
> In essense, by not binding applications to concrete (but inevitable
> changing) HTTP requests,
> we bind them to queries, which declarative indicate the data operation.
> These queries are then translated at runtime into concrete requests.
>
> An example of such an engine is Comunica:
> http://query.linkeddatafragments.org/
> It decomposes a query into HTTP requests, depending on the capabilities of
> the servers it talks to.
>
> Best,
>
> Ruben