[HN Gopher] Interoperable Serendipity
       ___________________________________________________________________
        
       Interoperable Serendipity
        
       Author : cxr
       Score  : 35 points
       Date   : 2021-10-13 12:02 UTC (1 days ago)
        
 (HTM) web link (noeldemartin.com)
 (TXT) w3m dump (noeldemartin.com)
        
       | dariosalvi78 wrote:
       | Why not xml and xml schemas?
        
         | degyves wrote:
         | In fact you can use XML, but not barebones XML. XML does not
         | contain semantics, which is needed to achieve interoperability.
         | So you should use some more specialized XML, namely, RDF/XML.
         | Which of course will increase complexity to XML. You can use
         | also JSON-LD, which is a more complex JSON bc it adds
         | semantics.
        
       | tconfrey wrote:
       | I love the idea of Solid and firmly believe that a user should
       | always own and be able to access and manipulate their data in any
       | application they are using.
       | 
       | However beyond syntax, semantic interoperability is always going
       | to be hard - maybe thats why we have standards organizations! I
       | remember the days of CORBA, and XML/SOAP/WSDL (then REST, JSON
       | etc), there is no silver bullet. Except in specific narrow
       | domains its hard to see how there can ever be serendipitous
       | interoperability.
       | 
       | Within specific domains tho maybe theres hope. I've always been a
       | plain text fan and am pleased to see the common usage of markdown
       | in a lot of modern note-taking apps - there's clearly
       | interoperability possible between Obsidian[1] and LogSeq[2] with
       | common markdown files.
       | 
       | The TODO app example from the article is an interesting space.
       | There are thousands of todo/scheduling/productivity type apps.
       | They should be able to plug and play from a common data store.
       | I'm personally banking on using org-mode as the data store for my
       | BrainTool app[3]. Its thus interoperable with the emacs org
       | ecosystem and other tools like LogSeq.
       | 
       | Org-mode is human readable and covers all the basics of headings,
       | todo's, links, timestamps, tables, checkboxes etc. I'd love to
       | see an ecosystem of serendipitously interoperable org-based
       | productivity and PMK products!
       | 
       | [1] https://obsidian.md/ [2] https://logseq.com/ [3]
       | https://braintool.org/2021/04/21/My-BrainTool-orgmode-and-em...
        
       | btbuildem wrote:
       | The crux of the problem lies in the semantic mapping (lenses /
       | shapes in the article) and the transformations potentially
       | required to map data that is not 1:1
       | 
       | Standards change / evolve, and for each "lens" you have an input
       | and and output schema to keep track of (and potentially, the
       | transformation logic associated with it).
       | 
       | This implies the existence of a transformation layer, capable of
       | both running the logic and accessing the data - which prompts the
       | question "where will this live".
       | 
       | In an adversarial interop scenario, I would expect the
       | "adversary" (the side making the effort) to be hosting this. In a
       | system built for interop from ground-up (yes, pipe dreams) it
       | could be a dedicated subsystem that also enforces access control
       | on the data.
       | 
       | It's definitely an interesting problem!
        
       | Vinnl wrote:
       | For those unfamiliar with the author, they're the developer of
       | the most prolific apps created to work with Tim Berners-Lee's
       | Solid: https://solidproject.org
        
       | andrewflnr wrote:
       | I think something intermediate between his two solutions could
       | work very nicely. Perhaps a set of competing translation
       | repositories, and asking the user which if any to use. There's
       | still a trust issue with the translations, but that's right the
       | problem we already have with open source, and the downsides are
       | probably more limited security-wise. You could still have the
       | option for the user to supply a translation. Having common
       | schemas that apps commonly target for bidirectional translation
       | increases the odds that you can have serendipitous inter-app
       | translation using only "first-party" translations by going
       | through the common format.
        
       ___________________________________________________________________
       (page generated 2021-10-14 23:02 UTC)