Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPLD implementation of Cmacc - #16

Open
HazardJ opened this issue Jul 6, 2016 · 8 comments
Open

IPLD implementation of Cmacc - #16

HazardJ opened this issue Jul 6, 2016 · 8 comments

Comments

@HazardJ
Copy link
Member

HazardJ commented Jul 6, 2016

The advantages of an IPLD implementation of Cmacc seem huge.

The goal of this Issue is to identify any issues in doing so.

At the Kantara Initiative BSC group, I (HazardJ) laid out what I see as a difference in the linking semantics - the use of "/" to denote transitions from one record to another and across indents (what's the name for this?) in a record.
https://kantarainitiative.org/confluence/display/BSC/Charter?focusedCommentId=81429144

Other than that, they look compatible to me, and IPLD is richer. It has the indent notion, which is very helpful, and has other data types, which would, I presume, allow integration of computational information along with the Cmacc text objects.

Fire away.

@HazardJ
Copy link
Member Author

HazardJ commented Jul 7, 2016

Providing some context:
IPLD is linking for IPFS - see https://github.com/ipfs/specs/tree/master/ipld
IPFS is ... the permanent web. An IPFS implementation of Cmacc would enable resilient, rapid, hubless sites, databases (IPDB) and the like. https://ipfs.io/
Cmacc is our shorthand for the CommonAccord linking and inheritance model. See, e.g. http://www.commonaccord.org/index.php?action=doc&file=S/About/Tech/Spec/0.md

@PrivacyCDN
Copy link

PrivacyCDN commented Jul 7, 2016

thanks!

(message trimmed by HazardJ)

@HazardJ
Copy link
Member Author

HazardJ commented Jul 7, 2016

In chat conversation with Willem, I suggested:

Cmacc can be described as three levels of expansion (2 currently implemented, 1 speculative):

  1. {variablename} in a value (k/v), expanded by matching "variablename" with a key name in a dictionary.
  2. [filename] in a dictionary, expanded by matching the name of another dictionary, from a list of dictionaries.
  3. [[folder]] in the list of dictionaries, expanded by matching another list of dictionaries.

All this can be understood as files in folders. It can also be done in any other format, including databases. It may be helpful to consider files in folders as the canonical form since they are i) widely used and understood, even by casual users, ii) the format of git and software collaboration.

.3. is currently not implemented, the sole dictionary is /Doc/ . (Though with the [?http://...] convention one can include other dictionaries ad hoc.)

.2. [file] has an "include as" notion - if the key is not blank, then the keys in the linked dictionary will be treated as prefixed by the key. ( 1.=[Z/ol/4] ). The {variables} in values in the linked dictionary will also be i) treated as prefixed, ii) if no match is found, treated by removing the prefix. Where there is recursive prefixing, the right-most prefix is removed first. (This deprefixing works exactly in Primavera's implementation. It is a consequence of her use of objects, rather than as a result of my specification. A very satisfying confirmation of the logic of the model.)

@jbenet
Copy link

jbenet commented Jul 9, 2016

Can you list a bunch of example paths here?

@HazardJ
Copy link
Member Author

HazardJ commented Jul 9, 2016

Thanks. Let me know if this is helpful.

A pretty good collection of the variety of key-paths and file-paths is in the file at http://www.commonaccord.org/index.php?action=source&file=Dx/Acme/02-NDA-With-Quake/0.md.

A sample of those:

Conf.Engage.Access.Sec={Conf.Engage.Access.Alt3.Sec}

Misc.Assign.1.sec={Misc.Assign.1.Alt1.sec}

These are matched via keys in files included as:

=[Wx/com/cooleygo/US/NDA/Form/0.md]

The ".AltN." examples are one of the few where I don't use a period to indicate a transition. Alt=[Z/Alt/4](deep in the NDA doc) could have been included as Alt.=[Z/Alt/4], but ".Alt.N." seems not to read as nicely as ".AltN.".

@chriscool
Copy link

My opinion is that, as it looks like you are happy with Cmacc, it is probably better to just be able to convert to/from an IPLD format for now. You could then decide and maybe change over time for which purposes you want to use IPLD/IPFS and for which purposes you want to use Cmacc.

@HazardJ
Copy link
Member Author

HazardJ commented Jul 13, 2016

Christian,
Thanks. Yes, that makes sense to me. @wilmveel and Axel are integrating IPFS support in the version that they are doing that uses a "." notation for delimiters. So we have a variety of approaches that I expect will converge. (http://github.com/wilmveel/common-accord)
Jim

@HazardJ
Copy link
Member Author

HazardJ commented Jul 27, 2016

I did a really rough (lawyerly?) use of IPFS at http://source.commonaccord.org/index.php?action=source&file=ipfs/QmbnngTXmT6XuVJzS2sbuuynQiy83ELU3bLXuKA8Yoczc7
I'm just using ipfs add and ipfs get on each file, but guess that this could be done with ipfs mount. I got tangled up on the install of go on OSX. Hope to get this solved so I can experiment further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants