by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 27 2019 06:08
    User @Mitzi-Laszlo unbanned @in1t3r
  • May 23 2019 06:49
    @Mitzi-Laszlo banned @in1t3r
  • May 16 2019 09:49
    @Mitzi-Laszlo banned @mediaprophet
  • Feb 01 2019 22:04
    User @melvincarvalho unbanned @namedgraph_twitter
  • Feb 01 2019 21:49
    @melvincarvalho banned @namedgraph_twitter
Martynas Jusevicius
@namedgraph_twitter
and very likely, by ignoring RDF and the Semantic Web, the developers are working against their own long-term interests
but i think it's human nature that makes it difficult to see beyond short-term
and it's similar with RDF/XML. it is not the most human-readable or best specified RDF syntax, but it does have its uses as a bridge to the XML ecosystem. which, as @csarven pointed out, has very powerful tools such as XSLT. you just need to know what you're doing
Martynas Jusevicius
@namedgraph_twitter
contrary to what many RDF people believe, a constrained RDF/XML profile can be successfully used for XSLT transformations (e.g. with XHTML as the output): https://www.w3.org/community/rax/wiki/Draft_Material#RDF.2FXML_.22plain.22_profile_suitable_for_XSLT_transformations
Martynas Jusevicius
@namedgraph_twitter
I think in large part browser vendors are to blame for abandoning declarative tech such as XSLT and pushing JavaScript exclusively. as a result, JSON became the leading format as it is native to JS. it is really it's only advantage over XML
Kingsley Idehen
@kidehen

@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 :)

Martynas Jusevicius
@namedgraph_twitter
those notions are still coming back to bite today :) e.g. http:// URIs used in namespaces cannot be upgraded to https:// https://sourceforge.net/p/saxon/mailman/message/36381737/
RDF/XML 1.1 could have fixed some of the major issues, but i guess the interest wasn't there...
Kingsley Idehen
@kidehen

@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 :)

Mark Hughes (happybeing)
@theWebalyst
@namedgraph_twitter and @kidehen this is very helpful to my understanding. Thanks. Keep it coming! :smile:
Sarven Capadisli
@csarven
@timbl We may agree and disagree to parts of this :) but I feel it is worth pointing out - to those that are interested in this topic - that while HTML without any embedded RDF is plain ol' Hypertext, with embedded RDF (RDFa, Turtle, JSON-LD, TriG, N-Quads) however, relationships between things can be expressed at the same granularity as Turtle, JSON-LD, .. alone. Language mixing makes that possible. For example, to the best of my knowledge, there is nothing in particular that can be expressed in Turtle but not in HTML+RDFa or vice-versa. Isomorphic strictly on the RDF language level. Plain HTML at best gets us relating documents, which is still a subset of relating things as I understand it. (Aside: links with fragments in hypertext documents at best points at nodes in documents, but that's no longer about RDF-y things.)
Sarven Capadisli
@csarven
To some extent it is valid (reasonable?) to have a hyperlink with a fragment referring to a local part of an external document in HTML (which doesn't have any embedded RDF.. so we're talking about just plain HTML), and to interpret that as a statement in RDF. (Aside: I can't recall how well this behaviour is described in specs, if at all.) It would just be a statement that's being made in the source document, and that's pretty much it. Following that link doesn't help us obtain more knowledge (using the RDF rules) about that object resource since there is nothing there to be found (based on RDF speak!) So, I generally agree with HTML alone is not "linked data" per se (or maybe even useful LD, if at all), but embedding syntaxes that are dedicated to express information using the RDF language brings HTML (as well as other languages that act as the host language to embed RDF eg. SVG, MathML) into the LD Web.
Sarven Capadisli
@csarven
To clarify the hyperlinking example: <a rel="license" href="https://creativecommons.org/licenses/by/4.0/">. An RDFa would probably return a statement along the lines of: <{baseURL}> xhv:license <https://creativecommons.org/licenses/by/4.0/>.
Sarven Capadisli
@csarven
s/An RDFa/An RDFa parser and Turtle serialiser
Ghost
@ghost~57bc59d440f3a6eec060e93b
@kidehen / @timbl my last note was an unsent draft, that appears to have sent for some reason. As you know, i've done a bit of work in the JSON-LD realm. What I didn't manage to author in that note (that wasn't Intended to be sent) was that n3 is a purpose built language, turtle is a subset.
There are nuances, that I've not been able to clearly describe to others. It seemed the easiest distinction to make, was to consider JSON-LD as a commercial upgrade path, or moreover an update path from json based APIs, et.al. anyhow, still trying to bring Into frame TimBLs earlier comments. ..
Kingsley Idehen
@kidehen

@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

Ghost
@ghost~57bc59d440f3a6eec060e93b
@kidehen cheers... U know that "stuff" has been bugging me for years... Good to see the crew more cohesive nowadays. Still lots of work to be done though. I have a bit to catch up on tomorrow. Night.
Kingsley Idehen
@kidehen

@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 [1].

[1] https://tinyurl.com/y9tfd8av -- a live example

Likewise, you can inject RDF into a structured data island within an HTML document [2].

[2] 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).

Vladimir Alexiev
@VladimirAlexiev
Hi folks! What do you think of GraphQL? I've looked into it and there seems to be a powerful movement. It's a bit of antithesis to REST (if you can live with this blasphemy for a minute ;-) in that the client says exactly what data it wants, rather than the REST endpoint spitting whatever data it is programmed to return. Also, you specify declaratively what data you have when you build a GQL service (using GQL types) and what services (queries, mutations, notifications), using a simple uniform manner. Such info could be done with some combination of RDF Shapes and HATEOAS (eg Hydra) but few people are doing it...
Gregory Magarshak
@EGreg
This is our new social browser coming out for mobile: https://projects.invisionapp.com/share/TKHYMVSJNW2#/screens
Thoughts?
Kingsley Idehen
@kidehen

@EGreg re. :point_up: August 13, 2018 6:40 PM, what mockup tool did you use?

Certainly looks cool :)

Ah! I see it is: https://www.invisionapp.com/#thisTool

Austin Wright
@awwright
I should say, I think properly understanding the proper semantics of documents *also a general Web problem.
Ghost
@ghost~57bc59d440f3a6eec060e93b
what’s the history of WebID vs. WebID-TLS - i’m particularly interested to know what role @bblfish played in the creation / advent of all that stuff...
Ilkka Huotari
@ile
The search here isn't the greatest, so I have to ask: is there a way to test WebID-TLS or WebID-OIDC somehow? I.e. is there a provider for those authentication methods available? I didn't find anything related to those at databox.me or solid.community (I created accounts to both).
That + an example app using those methods would be very nice.
Kingsley Idehen
@kidehen

@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.

Ghost
@ghost~57bc59d440f3a6eec060e93b
Is anyone interested in working on theory around how consciousness, and the use of ontological design (rdf + query lang + smart, dynamic agents) may influence our perception of reality. I have been working on seeking out a level of confidence, either way, as to preclude the possibility that a patent may be formed for commerical ownership whereby informatics practices designed to maintain a low distortion ratio, may or may not be subject to intellectual property law of a jurisdiction and it's means of support by way of international law. My questions are about the application of quantum physics related theory as applied to ontological design and it's employment by artificial agents; with an intended outcome of clarifying requirements in the interests of natural actors, as to ensure the ability for a person to define how they temporally define rules for the interaction of agents on their behalf, with other agents. I met / went to a meet-up today where https://en.m.wikipedia.org/wiki/Jonathan_Dowling spoke and despite best efforts overtime, am not satisfied with the analysis of possible risk factors as yet. If there are any such algorithic formula that could be patented, it is my opinion they should be in the public domain. But it's complicated stuff and i worry that I am concerned about issues that have no merit in the pragmatics of computer science; Nonetheless, I haven't found a good enough series of answers to set the matter aside. In effect, it's about whether technological means may be intentionally made use of on a proprietary basis to do this like, deciding elections prior to any vote, Or knowinglu providing false information in a descrete manner to manipulate decisions by targets; or, to willfully misinform dependents
to gain economic advantage. An example was used by another in the session by another, that he is able to stimulate the minds of mice to get a particular result such as to bring about an aggressive behaviour at will, using external stimuli; My question is fundamentally, can inforgs be used that way https://en.wikipedia.org/wiki/Inforg and if it is known that it can, are there patents? Is it still possible to ensure algorithms can be defined and used generically (is; between different, disparate providers) to ensure the lowest possible distortion ratio be available to the consumer / subject; does intellectual property law limit the availability of good information systems; by way of any intended, specified means (ie; employer, nationality, wealth, web service provider). Therein, the essence of my line of enquiry is about seeking to ensure people get to support their right to self determination by way of evaluating whether this is either not a problem, or a problem that has been compressively and pragmatically addressed; or one that may meritoriously be attended to.
James Marshall
@jmarshallcom_twitter

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!

Austin Wright
@awwright
@jmarshallcom_twitter That sounds more like https://www.scuttlebutt.nz/ which has a data model closer to Git, data is saved locally and optionally synchronized through servers
(Or a file transfer model? For data, Scuttlebutt uses JSON iirc, Solid uses an RDF data model which I think is better)
Melvin Carvalho
@melvincarvalho
@jmarshallcom_twitter hi & welcome! Solid allows a user to put their data where they want. Each choice will have different trade offs, but be capable of being mashed up together (e.g. in chat or a social time line). We have a few basic standards for encryption, but they've not been heavily utilized yet. Typically, we have back ends that are commodity, and front ends that live client side (but they dont need to). Solid can operate without a server, in theory, but the advantage of a server is that you have an always on connection, leading to a consistent user experience.
Tim Berners-Lee
@timbl
@jmarshallcom_twitter Welcome! Thank you for dropping in, and for your enthusiasm, and offer of help!
Mark Hughes (happybeing)
@theWebalyst
:+1:
Tim Berners-Lee
@timbl
If you look at the difference between a chat program in whoch the server is trusted and a chat program where the srever is not trusted, it would be nice for that to be handled by the layered architecture. For example, if yo look at what @theWebalyst has done, you can run the same app in https: space and/or in safe: space in which case the server is untrusted… you shoud even be able to make links betweent them.
By separating the apps from the choice of data store means we have a layer interface where we can do things like that.
Mark Hughes (happybeing)
@theWebalyst
@jmarshallcom_twitter FYI Tim is referring to this proof of concept (see link) - a Solid app modified minimally to operate on SAFEnetwork by providing an emulating LDP layer that can handle http: and safe: URIs. I'm not sure if this would be suitable for your architecture, but certainly interested to hear more about that. It sounds interesting :smile: Oh, here is the link I referred to, the video is only about ten minutes and gives a good summary of how Solid enables separating of application from data, and why this is - hopefully - such a game changer: https://safenetforum.org/t/devcon-talk-supercharging-the-safe-network-with-project-solid/23081?u=happybeing
James Marshall
@jmarshallcom_twitter

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).

Martynas Jusevicius
@namedgraph_twitter
user1 and user2 surely must have clients as well?
so those "nodes" really: clients and servers in one
James Marshall
@jmarshallcom_twitter
Yes, user1 and user2 would each be running their client-side software, and pass encrypted messages through the servers. Yes, each client side would include a local Solid server. This model would use Web protocols, but would not be on a website like other federated tools are. Or, optionally, a server could provide a Web interface for users who trust the server, but the user would be warned of any potential security downside of that. When someone befriends another who is on a Web-interface-providing server, they would also get a warning that they must trust that person's server with their data too (similar to how: I have a Gmail account, so anyone who emails me implicitly trusts Google with their emails to me).
Melvin Carvalho
@melvincarvalho
@jmarshallcom_twitter I think that's doable. I wrote a URL redirection service in a few minutes. Something like that could be made into a routing service. Lots of interesting use cases!
James Marshall
@jmarshallcom_twitter
I used to make everything Web-based so as not to require client-side software (which did expand my audience for other tools I've written), but the explosion of mobile apps has shown that today's users are willing to install a client-side app, especially for something as prominent as their social media tools.
Tim Berners-Lee
@timbl
Do have pointers to your previous stuff?
James Marshall
@jmarshallcom_twitter
@melvincarvalho yeah, it's occurred to me that the servers here could likely be made more general-purpose. For part of them, I could probably use existing HTTP proxies that support CONNECT, but they'll need a few other features too.
Melvin Carvalho
@melvincarvalho
@jmarshallcom_twitter solid servers actually have a proxy, but we've not found good ways to share them yet.
Martynas Jusevicius
@namedgraph_twitter
@jmarshallcom_twitter features like what?
James Marshall
@jmarshallcom_twitter
Sure, my main project since 1996 has been CGIProxy, a CGI-based "proxy" script that supports almost all Web pages through it, including those with JavaScript and Flash. The hard part is rewriting all the URLs in those resource types to point back through the same proxy-- that is what has required the most maintenance, since every JS API that's added may have some network-related properties and methods that have to be supported. Because of this, the software is a bit stale right now (latest release was July 2017), but I'm about to release a new version that again supports major sites. Its website is https://www.jmarshall.com/tools/cgiproxy/ ; let me know if you want to play with it, and I can email you the almost-released dev version.