@namedgraph_twitter regarding RDF-XML, the problem also became complicated by a combination of time and the general mindset around XML e.g., the notion that HTTP URIs didn't need to resolve which inadvertently lead to problems comprehending the utility of relative HTTP URIs that leverage "#" as an indexical.
In my experience, RDF-XML is a powerful notation for developing RDFizers (Transformers, Providers, Connectors) that emit 5-Star Linked Data.
Since 2007, we have developed close to 100 transformers for various APIs and Document Types using RDF-XML and XSLT. The key for us is keeping that in the box we call the Virtuoso Middleware Layer (a/k/a Sponger) i.e., users do not encounter RDF-XML at all, they simply enjoy the data wrangling and transformation benefits it provides :)
@namedgraph_twitter : All we can do (IMHO) is put our heads together and collaborate our way to a time and place where coherent use and understanding of what constitutes a Semantic Web permeates a majority of applications via the frameworks and libraries from which they are developed.
That would make things solid :)
@mediaprophet : To cut a long story short re. JSON-LD:
In its current form, it doesn't handle relative HTTP URIs properly.
Here's a lengthy thread that concludes with a fix to this particular JSON-LD bug -- that's part of the next release: json-ld/json-ld.org#488
@csarven re :point_up: August 13, 2018 11:12 AM, the issue is that HTML (Hypertext), RDF, Linked Data (Hyperdata or Linked Data [when Linked Data principles are applied to RDF]) are distinct languages targeting different problems.
Naturally, you can use raw HTML as the object of an RDF relation .
 https://tinyurl.com/y9tfd8av -- a live example
Likewise, you can inject RDF into a structured data island within an HTML document .
 https://www.uniprot.org/uniprot/P02741 -- a live example
Structured data islands within an HTML document doesn't immediately help users and developers to properly understand the fundamentals of a Semantic Web i.e., we don't reach that point of critical clarity required for making this stuff explode by way of serendipitous discovery and surreptitious content curation.
Personally, I believe dokie.li presents a powerful solution and opportunity (project wise) to address the important challenge outlined above. The critical todo is getting its binding to solid sorted out, which inevitably means getting solid's authentication sorted out, and as you can see we are heading into a strange loop++
Fundamentally, end-users should just enjoy the power of a Semantic Web while developers should be encouraged to write applications for the real-world that actually leverage real-world modeling rather than sticking to a broken fad-driven pattern that fixates on syntax and runtime object interaction [where said objects have no real-world semblance).
@ile re :point_up: August 14, 2018 5:48 AM, there are a collection of live solid-server pods at: https://github.com/solid/node-solid-server/wiki/Running-Test-Implementations-of-Solid-compatible-servers .
My pod is https://kidehen7.solid.openlinksw.com:8444, and it will authenticate WebIDs using either WebID-TLS or WebID-OIDC protocols.
Hello, new member here. For years, I've been planning to write a secure federated social media platform (in particular, useful for vulnerable communities globally), and was excited by the Solid talk and demo at DWEB a couple of weeks ago. My planned platform would remove the need for users to trust their servers: client-side software would do almost everything, and the servers would do little more than pass encrypted messages between their users and other servers. This makes it architecturally different from most other federated servers, and likely more secure. I've read most of the relevant W3C Social Web standards, and they don't seem to directly accommodate this model, but could mostly still be used (e.g. my tool's client could access a local-only LDP/Solid server, use ActivityStreams vocabulary, etc.). At the DWEB demo, Tim asked what features social media tools might need in Solid etc., so my request would be to consider this non-server-trusting model along with all the others. Happy to share the technical details with anyone interested.
Also, I'd love to get involved in these projects! I've helped develop a few technical standards and implemented many, and could, say, write relevant libraries to support these standards. What kind of stuff needs doing? I can't commit to full-time immediately, but could likely get funding to help. Is there a TODO list of major tasks?
Thanks! If there's a better forum for this, let me know. Looking forward to a world with better social media!
Thanks for the welcomes! Scuttlebutt is interesting, but has certain limits I don't want. Scuttlebutt-through-Tor might provide the security I intend.
Yeah, servers are more likely to be always on... that's an issue I haven't solved yet, but for very privacy-centric users the best-possible solution here might be good enough. Each person would store a copy of each friend's public data (or that which is available to friends), and perhaps if a friendship is started through another friend, the public data could be gotten from the common friend? I'm not sure, still thinking about it. Each client would cache a lot of data, to mitigate the problem.
Thanks for the comment about Mark's chat tool, Tim! I'll have to check that out. And thanks Mark for the link.
To clarify, the encryption I'm thinking of would be layered a la onion routing: If user1 (on server1) wants to send a message to user2 (on server2), the message is encrypted for user2, then the result is encrypted for server2, then for server1, and then sent to server1 (which decrypts it and only then knows to forward it to server2). That way, each server gets a minimum of metadata, and doesn't even know which users know each other (though they may eventually be able to infer some of that).
Cool about Solid proxies, I'd love to explore them!
Other features servers would need include at least user account management. A server wouldn't need its users' data, but it would need to maintain a list of logins, and it will probably keep a connection open to each user when they're using it in order to deliver messages and notifications synchronously (asynchronously when the user is not connected).