On Sat, 27 Apr 2019 at 10:56, Henning Sato von Rosen < henning.von.ro...@gmail.com> wrote:
> Thanks a lot for the background on RDF and links, very interesting indeed! > > About FOL, you equal the properties that we are talking about to > predicates in FOL. > Firstly it's important to say that I don't claim they are identical, just analagous, as they have many differences too. spec isn't realy a logic system, though I guess you could think of it that way, particularly when looking at the generative aspects. It's perhaps therefore important to clarify which aspects of clojure properties I'm drawing an analogy to. My previous claim was this: >> I'd argue (with no authority) that FOL is likely the true source of the decomplected properties from maps idea in clojure; which is analagous to what happened in KR. Where I'm really talking about the use of keywords in clojure.spec; which I'd say are similar to (definitely not the same as) binary predicates in FOL. The similarity I'm alluding to is that in FOL the use of predicates are largely extrinsic to their subjects. For example I can make statements today such as "Socrates influenced Rick" where *influenced* (the predicate), was not intrinsically baked into Socrates at his birth; but was derived independently later. Likewise with properties in spec the predicate is decoupled from its subjects. My claim is that this is similar to adding a new spec to some existing data. And it's also like adding a new property (keyword) to a map in spec, and only handling what you know. > I might have gotten it backwards here, but isn't the natural thing to > think of our *map* as the relation (predicate) and our *properties* as > the slots of the predicate > The analogy may break down if you think about it too much; as spec has a different usecase to FOL. You could probably model things this as you suggest however that isn't how I was thinking of it. To expand, I'd say that this: (s/def ::influenced #(instance? Person %)) Is analagous to declaring the meaning of a predicate; e.g. in the prose of a paper you might say "we define influenced as a relation between two people". Or in RDF this is equivalent to defining the predicate in a vocabulary e.g: :influenced rdfs:Range foaf:Person . :influenced rdfs:Domain foaf:Person . and something like this is roughly equivalent to expressing the relation between Socrates and Rick: i.e. the maps themselves are the subjects and the keyword is the binary relation between them: (assoc socrates ::influenced rick) A notable difference here is that spec doesn't let you describe the domain of a keyword in a map; i.e. an `(s/def ::keyword ,,,)` only lets you make a statement about the value of the key, not the map it is part of. Though you can of course do that with an extra s/keys spec, it's a new spec with a new name and not a property of the initial spec. Obviously you can also use specs to desribe other things (not just the values of maps), but the primary similarities as I see them are that it is open for extension by virtue of: 1. The predicate/spec is extrinsic to the data/declaration/code itself i.e. they can be coined separately at a different place and time 2. That multiple a single subject/datum can have a plurality of specs 3. That you can't close the world (and prevent others saying things about your data) In a frame based system Socrates would typically be closed to other people adding new properties... though IIRC there may also have been some hybrid approaches, e.g. I've heard that there were some Common Lisp truth maintainance systems which could dynamically introduce new slots on classes through rules expressed in non-monotonic logics... but this is largely hearsay and likely irrelevant here :-) Hope this clarifies things a little... R. (positional arguments being isomorphic (more succinct, but less readble > and less flexible) to named roles of map datastructures)? > > Reards/Henning > > On Fri, Apr 26, 2019 at 12:58 AM Rick Moynihan <rick.moyni...@gmail.com> > wrote: > >> Having used both Clojure and RDF extensively I can say that there are >> many similarities between these two worlds, and the influence of RDF on >> Clojure isn't just something Rich say's, it's very apparant. >> >> I may be mistaken in some of the details here, but as I understand it in >> the world of GOFAI (Good Old Fashioned AI) and KR (Knowledge >> Representation) there were "frame languages" popularised by Minsky: >> >> https://en.wikipedia.org/wiki/Frame_language >> >> where you essentially describe the world in terms of classes, and classes >> consist of sets of slots or properties, you may have inheritance etc... >> essentially classical OOP. >> >> In the other KR camp however you have First Order Predicate Logic (FOL), >> where the predicates (properties) essentially take centre stage, and >> describe relations between objects. This modelling camp is largely where >> RDF drew its inspiration for modelling from in the form of RDFS and OWL. >> I'd argue (with no authority) that FOL is likely the true source of the >> decomplected properties from maps idea in clojure; which is analagous to >> what happened in KR. >> >> I mention frame languages, as I suspect there is a lot of academic >> discourse on the pros and cons of frame based approaches vs FOL, which may >> be relevant. >> >> In RDFS (RDF Schema: https://en.wikipedia.org/wiki/RDF_Schema) and OWL ( >> https://en.wikipedia.org/wiki/Web_Ontology_Language )you essentially >> describe the domains and ranges of properties, and then use properties to >> tie things together. In these languages you don't think of classes as >> constraining the available properties. Infact properties often let you >> infer the class of something, for example if you learn that :Rick >> foaf:friend :Bill you also learn that :Rick and :Bill are foaf:Person's >> too. This enables anyone to say anything about anything in RDF which is >> why it's an open world system, where as frame based systems are typically >> closed world, as you can't add properties to something without changing the >> class. >> >> RDF and OWL aren't really constraint languages though, they're >> description logics; so they don't typically let you restrict the values of >> things, instead they let you infer new values. However recently there have >> been moves to standardise ways to check RDF graphs form a certain well >> specified shape. This has been in the form of the languages SheX and SHACL >> (now a W3C standard: https://www.w3.org/TR/shacl/ ). >> >> I find it remarkable how similar these languages are to spec; though I >> don't think spec drew any direct inspiration from them. I guess you just >> end up in a similar place if you share a property oriented view of the >> world. >> >> If you're interested in these languages this is a good online book on the >> topic: >> >> http://book.validatingrdf.com/index.html >> >> RDF also has a lot in common with Datomic in that you describe data with >> triples EAV(T) in datomic and SPO(G) in RDF. Likewise SPARQL and Datomic >> have a common ancestor in Datalog. >> >> I believe another non RDF influence for spec is this paper: >> >> http://matt.might.net/papers/might2011derivatives.pdf >> >> Please take all of the above with a pinch of salt though, it's at best a >> crude approximation on the lineage of these ideas... >> >> R. >> >> On Thu, 25 Apr 2019 at 08:16, Henning Sato von Rosen < >> henning.von.ro...@gmail.com> wrote: >> >>> On Thu, Apr 25, 2019 at 2:32 AM <dus...@hyperfiddle.net> wrote: >>> >>>> A lot of the attribute-centric thinking is inspired by RDF and >>>> linked-data >>>> >>> >>> Yes! Rich mentions that as well. So I tried to look into RDF, but it is >>> huge! If anybody has a good link to material relevant to this discussion, >>> I'm thankful, but at the time being we will likely not have time to dig >>> into RDF. Rich's explanation is by far the most relevant andaccessible >>> I've come across. >>> >>> Regards/Henning >>> >>> >>> >>> >>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To post to this group, send email to clojure@googlegroups.com >>>> Note that posts from new members are moderated - please be patient with >>>> your first post. >>>> To unsubscribe from this group, send email to >>>> clojure+unsubscr...@googlegroups.com >>>> For more options, visit this group at >>>> http://groups.google.com/group/clojure?hl=en >>>> --- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "Clojure" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/clojure/Dbh-5kNYKgE/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> clojure+unsubscr...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/clojure/Dbh-5kNYKgE/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
