lyxsus

Why not? It may be stupid, but I'm buying it if material feels right to my skin.

Is Hamas and Iran yours?

UNRWA is compromised as hell, ofc it must go, so it's a pretty good use case for ethical ads usage. Definitely not a reason to enforce an additional censorship.

  Location: Buenos Aires, Argentina
  Remote: Yes
  Willing to relocate: Depends
  Technologies: JavaScript/TypeScript, NodeJS, React, Graphl, Relay, Apollo, Nextjs, Python, Postgres, Mongodb, Couchdb, Dynamodb and etc and etc. AWS/GCP. RDF/OWL/RDFS, langchain/langgraph.
  Résumé/CV: https://drive.google.com/file/d/1m4A_XFaPKFqUky2n3WdGsFpXWuALTPd2/view
  Email: lyxsus@gmail.com

This is incredible. I really want it to take off.

omg. ok, adopting some F features is an interesting idea. but why are they trying to make that thing with syntax happen?

tbh, tailwind feels like the worst thing that happened to frontend dev since coffee script.

semantic web forcing everything into a single schema

I don't think "forcing" is the right word here, I think the right one would be "expects it to converge under practical incentives". That's a more gentle statement that reflects the fact, that it doesn't have to for SW tech to work.

Also, the term "schema" is a bit off, bc there's really no such thing in there. You can have the same graph described differently using different ontologies at the same moment without changing underlying data model, accessible via the same interface. It's a very different approach.

never the way computers or humans structure data in order to work with it

If you haven't mentioned that you had an experience, I would say you confuse different layers of technology, because graph data model is a natural representation of many complex problems. But because you have, can I ask you to clarify what you mean here?

Academia sells the straight jacked of the semantic web as a life long free lunch at an all-you-can eat-buffet

I disagree, bc I in fact think that academia doesn't sell shit, and that's the problem. There's no clear marketing proposal and I don't think they really bother or equipped to make it. There's a lack of human-readable specs and docs, it's insane how much time you need to invest in this topic even just to be able estimate whenever it's a reasonable to consider using SW in a first place. Also, lack of conceptual framework, "walkthroughs", tools, outdated information, incorrect information drops survival chance of a SW-based project by at least x100. But it can really shine in some use-cases, that unfortunately have little to do with the "web" itself.

Oh, I would like to see a look on your face when just in about 100-200 years from now it will be mature enough for a "web scale".

Understood, thank you.

Yes, that's not solvable with just OWL (though it might help a little) or any other popular reasoners I know. There're papers, proposals and experimental implementations for generating probability-based inferences, but nothing one can just take and use, but there're tons of interesting ideas on how to represent that kind of data in RDF or reason about.

I think the correct solution in SW context would be to add a custom reasoner to the stack.

so if it tries to have a unified ontology that's why it's destined to fail, but if it's designed to working with many small ontologies… that's why it will fail! lol, but you can't have it both ways.

In SW, the "semantic" part is subjective to an interpreter. You can have different data sources, partially mapped using owl to the ontology that an interpreter (your program) understands. That allows you to integrate new data sources independently from the program if they use a known ontology seamlessly or create a mapping of a set of concepts into a known ontology (which you would have do anyway in other approach). So in theory, data consumption capabilities (and reasoning) grows as your data sources evolve.

If what you describe is the semantic web, the Semantic Web is "JSON", and solved.

It has nothing to do with JSON, JSON-LD, XML, Turtle, N3, rdfa, microdata and etc.. RDF is a data model, but those are serialisation formats. That's another interesting point, because half of the people talk only about formats and not the full stack. That's not a reasonable discussion.

which certainly doesn't match what everyone else says it is

oh, I know it and it's upsetting.

That's a valid point, but I'm not sure, the following problem has a technical solution:

Clear indicators the owl author didn't know the domain

There're a lot of wrong perspectives on the topic in this thread, but this one I like the most. When someone starts to talk about "agreeing on a single schema/ontology" it's a solid indicator that that someone needs to get back to rtfm (which I agree a bit too cryptic).

The point here is that in semantic web there're supposed to be lots and lots of different ontologies/schemas by design, often describing the same data. SW spec stack has many well-separated layers. To address that problem, an OWL/RDFS is created.

Isn’t it similar to linear types in haskell?

We’re not, but your point is still valid.

If you open specification linked to that page ( https://wicg.github.io/sanitizer-api/#sanitizer-api ), you'll see that Sanitizer constructor accepts config param, that does exactly that and will probably extended before spec is ready.

Location: Saint-Petersburg, Russia

Remote: Yes

Willing to relocate: Yes

Technologies: Javascript/TypeScript, React (Relay/Redux/Apollo), Postgresql/Mysql/NoSQLs, K8S, Python

Résumé/CV: http://lyxsus.github.io/Sergey_Antoninko_CV-2021-04.pdf

Email: sergey.antoninko@gmail.com

Fullstack developer (~15 years).

As a non-US citizen, I have 3 questions:

1. WTF

2. Is it even enforceable?

3. Does anybody know recent examples?

However, there now exist a number of contexts in which namespace prefixes can impart information value in an XML document.

Well, yeah. They've given up to a mass amount of half-ass implementations? So what? I think it's our moral duty to ignore it :)

I would say use XML Schema at least. DTD looks alien to XML anyway.

It doesn't affect data model encoded in document even a tiny bit. Namespace prefixes are irrelevant. If changing these prefixes breaks the program, the program is incorrect.

Well, yeah, true.

I believe it's mostly implementation and popularisation problems.

The w3c specs surrounding xml/xpath/xslt/rdf and etc are very well designed but it's possible to appreciate them only after you spend ridiculously unreasonable amount of time reading and putting them all together. Otherwise it looks like a stupid pile of complexity with no purpose.

And what upsets me the most is the lack of really good libraries, everything I worked with just sucks so much.

I still have a hope that maybe in 5-15 years things will change.

That doesn't seem accurate at all. It would be the case if there was some deterministic abbreviation from URL namespace qualifiers down to namespace prefixes, but there is not;

I'm not sure what you mean by that, tbh. It seems to me that namespace expansion is absolutely straightforward and deterministic. There're scopes, yes, but they're too well-defined (if that's what you mean).

What do you suggest to use instead? It's a bit too early to use RDF, people haven't catch up yet.

This breaks people's mental models of how XML works, and correspondingly, breaks people's code that manipulates XML.

Because they usually have incorrect mental model. Blaming namespaces for name ambiguity would be the same as blaming the code "x = a + b" because "a" and "b" could be defined differently.

Namespace prefixes are absolutely irrelevant, they only exists for your convenience.

Sure, but what’s the end goal here? I just don’t get what prevents the history to repeat itself if it lifts off.

And considering current web, which of these problems are technically unsolvable at the moment? We can have privacy-aware browser if we’d want to. Protocols are mostly ok. HTML and css are actually good in 2020. Javascript can be disabled. Ads are filterable and there’s nothing preventing it from spreading by other other channels.

If that’s conceptually just a downgrade to bare minimum, how is it much better than lynx?

Why?

I believe all data warehouses are limited by the quality of their data model.

wrt that, what do you think about Solid from Tim Berners-Lee? (solidproject.org)

Why don’t you just quote the word “by”? I agree with the word “by”. I fully support it and appreciate how precise and representative it is with respect to the topic. Thank you for walking that path with me, I am defeated by your debating skills and have no hope to recover.

In general. In general what?

You can't take an advantage of having an abundant amount of data about data sources, schema and query you're about to execute (in general)? The original example simply illustrates that if you have the right problem and understand it well, you can work on it a bit and make it look like magic. It says "G has some property, that lets us do X to solve problem Y", to what the other guys says "No, G doesn't have these properties, because you can't apply X to solve Z. And W." How dumb is that?

It's not an alternative to SQL in general and it's not a drop-in replacement for backend. Do you realise, that I can run graphql entirely in browser and make resolvers call the same rest api? That'll work pretty well. Or that also looks too problematic?

we are mostly concerned with how it applies to the vast majority of people and applications

Applications – yes, people – no. In last couple of years I saw a few dozens implementations of graphql on a backend and I think only 2-3 were really good. The rest is usually a complete clusterfuck and I wish they didn't use it and never touched it. But that's also true for too many other things. So maybe you're right. Maybe if somebody realises that his competence isn't enough, it's better to stay away.