Re: EasierRDF

Hi Melvin,

I think the inline answering is starting to lead to two parallel conversations, so let me summarize my understanding (correct me if I’m wrong!):

Your view: someone defines a JSON API with a description (among others) of terms used in its JSON objects; people read this API spec and program their JS code accordingly. In case folks only work with a few APIs, this is fine and much easier than working with linked data.

My view (sorry, my summary is longer – for obvious reasons, i.e., I know more about my viewpoint :-). Many JSON APIs will speak about the same thing, using either the same terms (name) or different ones (born vs. birthplace vs. birthdate; Korean versions..). People wanting to work with these APIs may thus have to code their JS slightly differently for each API, although they are often consuming the exact same concept. Instead, if each JSON API relies on a well-known vocabulary (e.g., FOAF), they simply mention that; people don’t have to read another API spec and simply re-use the same JS code for each API.

E.g., given event or product information in schema.org, published by a multitude of websites / APIs, folks can simply program their JS code around schema.org and call it a day. As said, this is not relevant in scenarios where folks only consume from a single API – it targets a more distributed Web where clients may consume many websites / APIs.

I very much like your idea of a lightweight, tiny, and incremental SW, where developers can utilize JSON-LD in increasingly complex ways to suit their needs. I think a lot of the tooling is already there to support this.


William


                Let me clarify my question – are they agreed-upon terms or is everyone free to define their own keys?

Nobody needs to agree on a json key, people just use strings in their APIs and accept that in rare cases there will be collisions

BUT if you really want name spacing, you can add it

ie best of both worlds


I believe you’re equating the utility of ontologies with inferencing (correct me if I’m wrong), but IMO their core purpose is precisely to define shared vocabularies for concepts like these (first/last name, birthdate, birthplace, ..) (A.k.a., a “shared conceptualization of a domain”.). Software clients, programmed to recognize a set of well-known vocabularies, can understand all content published using those vocabularies.

The taxonomy and name spacing is useful

But so often they are human readable guides, rather than pulling in the triples and inferring from them.  Sometimes the machine readable triples are missing, and the s/w doesnt really notice

                Oh yeah I agree with you there. A major problem is that most namespace IRIs cannot be de-referenced after a while (when folks lose interest, or funding runs out). Well, since they’re IRIs, it’s not mandatory they can be resolved to begin with, it’s just good practice. But IMO this doesn’t take away the usefulness of namespaces acting as, well, namespaces for vocabularies.

That's exactly the point I wanted to make.  There's about 600 vocabs out there in LOV, and while I love the idea of reuse, many are simply not updated, and can take years to get your own term upstream.  Developers sometimes cant wait that long


Re the discussion around “ex:” – of course, if everyone uses their own vocabulary this will defeat the whole purpose. I don’t think that was the takeaway of that example (it rather concerned the Turtle vs. JSON syntax).

So, I was saying that JSON is simpler for web devs.  The ex: vocab if it's relative, which I expect, would ensure that keys are NOT matched.  In JSON APIs they are matched by keys.

I’m confused about this statement. A relative IRI such as foaf:name would be resolved to an absolute IRI http://xmlns.com/foaf/0.1/name during parsing, which can be perfectly string-matched to the resolution of another term. (Or, maybe I misunderstand what you mean by “relative”?)

Confusion arose because ex: wasnt defined, so i had to guess what it meant (it is important)

- if ex = example.org<http://example.org> -- that's not really even a vocab, just a namespace
- if ex = '#' which is in the JSON-LD best practice doc, then every predicate becomes different and does not match

If doing string matching, you just compare the json terms and you're done.  What's not to like? :)


                This is assuming that the RDF snippet is syntactically valid and defines the utilized namespaces. (Hans’ example didn’t do this, since its focus, AFAICT, wasn’t on namespaces but rather ease of syntax.)

JSON keys OTOH are simply JSON keys and can be compared character for character
So are RDF terms :-) A client that is pre-programmed with a known set of vocabularies can compare the found RDF terms character-by-character to their programmed vocabularies, and then do something useful with the data.

As I said, not with relative URIs.

                Nope (unless I misunderstand what you mean with “relative”).

Lack of explanation of what ex: was lead to some confusion, I hope I've clarified above


It's also not back compat with regular JSON.  Dont you think RDF would be so much better if every JSON API on the web would work with it?

                I totally agree with you here – JSON is natively supported in JS, while RDF is not. I assume that’s also what you mean by “JSON doesn’t need a parser” – of course it does, but once it’s parsed (e.g., using JSON.parse) one can work with JSON as native constructs in JS.

Yes, you're absolutely right.  JSON requires a parser, it's just ubiquitous


                That said, there are the NS.js<https://github.com/rdfjs/N3.js/> and graphy.js<https://github.com/blake-regalia/graphy.js> libraries that allow one to handle RDF in JS quite easily. E.g., graphy.js allows one to “Construct RDF data using ES object literals that reflect the tree-like structure of quads, graph -> subject -> predicate -> object, including nested blank nodes and RDF collections.” This actually got me interested in trying out this library (maybe there isn’t such a big impedance mismatch between RDF and JS!)

The devil is in the detail here, I know this for working for 15 years with what became rdflib.js.  The problem is having to support legacy formats dating back to 2002 introduces an exponentially increasing surface of bugs.  While that might be a feature not a bug for consultants improving the RDF experience, it makes life harder for devs getting started and those wanting to build quickly

Case in point "easier" RDF is how many pages long, including reference?  10?  100?  1000+?  Probably the latter if you really want to understand it

Why couldnt we have a lighweight and "tiny" semantic web which developers can user reading no more than half a dozen pages of spec.  ie "easier" RDF is too long, linked objects is too short ... something like a 6 page max (preferably shorter) lite spec to get web developers going



William


__________________________________________
From: Melvin Carvalho <melvincarvalho@gmail.com<mailto:melvincarvalho@gmail.com>>
Sent: maandag 14 februari 2022 15:49
To: Frederik Byl <frederik.byl@gmail.com<mailto:frederik.byl@gmail.com>>
Cc: Semantic Web <semantic-web@w3.org<mailto:semantic-web@w3.org>>; David Booth <david@dbooth.org<mailto:david@dbooth.org>>
Subject: Re: EasierRDF



On Fri, 11 Feb 2022 at 13:24, Frederik Byl <frederik.byl@gmail.com<mailto:frederik.byl@gmail.com>> wrote:
Dear community,

I came across the project https://github.com/w3c/EasierRDF. I think it is a good idea to have a look at RDF and the challenges it has. I'm struggling with the use, because the work that is necessary to make systems interoperable by understanding ontologies, formatting the data, extending ontologies, writing queries, etc, is huge! I am a big fan of graph databases and the ease of using Neo4j, Cypher, plain json and writing converters between readable json formats is so much faster and developer friendly. Queries in Cypher are intuitively and can be understood on sight. I am also looking at Solid and I find the approach of data pods extremely interesting and relevant, but the structure is so overwhelming and overcomplicated that I start losing faith in this. Since the project EasierRDF is started, I guess others struggle with the same? Are there some major advantages of using RDF and Sparql over Neo4j and Cypher? We could do linked data with Json-ld and Neo4j?

I came to realize than in 15 years of heavy RDF use, the useful 10% is what I use 90% of the time

You might want to look at this one-pager which tries to take some of the useful bits of RDF (@id @type @context) and add it to JSON

https://linkedobjects.org/

It is for beginners getting started, and has an upgrade path to JSON-LD and full RDF, for those that want it.  It's also compatible with plain old JSON, without needing the overhead of creating and maintaining ontologies (which let's face it, almost no one does or cares about today)

Use cases and libraries are yet to be built out, but hopefully some food for thought


Thanks

Kind regards,
Frederik

---------- Forwarded message ---------
Van: David Booth <david@dbooth.org<mailto:david@dbooth.org>>
Date: do 10 feb. 2022 om 16:56
Subject: Re: EasierRDF
To: Frederik Byl <frederik.byl@gmail.com<mailto:frederik.byl@gmail.com>>


Hi Frederik,

You are asking an excellent question, and I think the community as a
whole would benefit from discussing it on a public list, both to get
more viewpoints and to expose your question to other existing RDF users.
  Would you be willing to post your question to the public
semantic-web@w3.org<mailto:semantic-web@w3.org> list?
https://lists.w3.org/Archives/Public/semantic-web/

Thanks,
David Booth

On 2/10/22 10:43, Frederik Byl wrote:
> Dear David,
>
> I am sorry to contact you in this straightforward manner. I came across
> your project https://github.com/w3c/EasierRDF
> <https://github.com/w3c/EasierRDF>. I think it is a good idea to have a
> look at RDF and the challenges it has. I'm struggling with the use and
> the work that is necessary to make systems interoperable by
> understanding ontologies, formatting the data, extending ontologies etc,
> is huge! I am a big fan of graph databases and the ease of using Neo4j
> and plain json and writing converters between readable json formats is
> so much faster and developer friendly. I am also looking at Solid and I
> find the approach of data pods extremely interesting and relevant, but
> the structure is so overwhelming and overcomplicated that I start losing
> faith in this.Since you started the project Easier RDF, I guess you
> struggle with the same, or do you see some major advantages in using RDF?
>
> Thanks
>
> Kind regards,
> Frederik