profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/maximveksler/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Maxim Veksler maximveksler Tel Aviv, Israel https://seed-x.com Software Team Lead at Seed-X. Knowledge graphs advocate.

maximveksler/awesome-wwdc 54

A curated awesome WWDC resource list for conference attendees

maximveksler/awesome-serialization 5

Data formats useful for API, Big Data, ML, graph & co

maximveksler/boto 1

Python interface to Amazon Web Services

maximveksler/Clean 1

See how different tools affect your Xcode project settings

maximveksler/cryptosphere 1

A global decentralized encrypted datastore with anonymous publishing

maximveksler/action 0

a GitHub action to run `pre-commit`

maximveksler/AltBeacon 0

AltBeacon is an alternative to iBeacon that allows iOS devices to be advertised in the background, which is not currently possible with iBeacon.

maximveksler/AMNGlobalUtilities 0

Collection of useful macros and utilities for Cocoa, iOS development

maximveksler/articles 0

Weekly articles for NSHipster.com

startedDanko-Lab/TED

started time in 5 hours

startedgoogle/xarray-beam

started time in 5 hours

startedNathanSkene/MAGMA_Celltyping

started time in 9 hours

startedNetflix/metaflow-tools

started time in 9 hours

startedobservablehq/plot

started time in 11 hours

startedsalesforce/DazedAndConfused

started time in 16 hours

startedNCAS-CMS/cf-python

started time in 16 hours

startedNetflix/metaflow

started time in 17 hours

startedsn-GT/WGS_AfricanAmericans_IBD

started time in 17 hours

startedAmpersandTV/aesara-hmc

started time in 18 hours

startedmmhs013/pyMannKendall

started time in 18 hours

startedhteumeuleu/caniemail

started time in 18 hours

fork mattt/dependabot-core

🤖 The core logic behind Dependabot's update PR creation, and the public issue tracker for all things Dependabot

https://github.com/features/security

fork in 19 hours

release Callidon/setup-hdt-action

v1.2

released time in a day

release Callidon/setup-hdt-action

v1.1

released time in a day

startedstripe/stripe-react-native

started time in a day

startednektos/act

started time in a day

created repositoryTScafeJR/autocomplete-demo

created time in a day

startedcockroachdb/apd

started time in a day

startedCOMBINE-lab/alevin-fry

started time in a day

release Callidon/setup-hdt-action

v1

released time in 2 days

issue commentw3c/EasierRDF

Property Graphs

I say the best way is to create a new vocabulary. Here is a sketch. I use prefixes to make clear what I mean:

  • Def: A pg:Entity is a rdf:IRI (but not vice versa); its type is an pg:EntityType
  • Def: A pg:RelationType is a subclass of rdf:Property with domain and rage pg:EntityType
  • Def A pg:Relation is a rdf:Statement with subject and object a pg:Entity and predicate a pg:RelationType
  • Def: A pg:PropertyType is a subclass of rdf:Property with domain pg:Entity
  • Def: A pg:Property is a pair (pg:PropertyType, value). A rdf:Statment is interpreted as pg:Property if the predicate is a pg:PropertyType or the object is a rdf:Literal or Blank Node (indicating a complex property value)
  • pg:Properties can be assigned to reifed rdf:Statments

Example:

ex:Alice a ex:Person ;
   ex:name "Alice";
ex:likes ex:Bob ;
ex:employedAs ex:Scientist .

ex:Bob a ex:Person .

# new Property-Graph Ontology

ex:Alice a pg:Entity .
#OR
ex:Person a pg:EntityType . 


ex:name a pg:PropertyType . # can be inferred
ex:likes a pg:RelationType.  #  can be inferred ?
ex:employedAs a pg:PropertyType # this cannot be inferred and must be asserted!

 

draggett

comment created time in 2 days

issue commentw3c/EasierRDF

Property Graphs

Named graphs as property value? I didn't think about it, but this is a very interesting idea. Why not?

The link you provided is good example for what I mean: you must specify a mapping. If the PG side is the active consumer, the problem is not only a technical, because you know how to map. But there is general solution without any additional information.

draggett

comment created time in 2 days

issue commentw3c/EasierRDF

Property Graphs

Can you use named graphs as "sub-graphs"?

And have you looked at other RDF -> PG mapping approaches? For example: https://github.com/Rothamsted/rdf2pg#mapping-rdf-to-cypherneo4j-entities-general-concepts

draggett

comment created time in 2 days

issue commentw3c/EasierRDF

Property Graphs

Thank you all for reading me note and making this excellent remaks!

@HughGlaser Your summarised my thoughts very nicely. Maybe the term "expressivness" is misleading. It did not mean that either graph style is more powerful. As you said they both can model the world but they do it differently.

I will try to respond to your objections. They all come down to the questions: is the property/relation question is a real deep issue or is it a superflous pettifoggery of a shallow difference? If there are differences, can they be listed (are the sufficient arguments for beeig a property or relation?)

The answer may be a bit surprising. I used the term "graph style" for a reason. There is the concept of Thought Style. It is an important concept in the field of history of sciences, it is the basis of the concept Paradigm. To simplify it: you have a style of thinking that is shaped by your context.

I make a hypothesis: there are two thought styles here, the context of RDF/Linked Data and the context of Property Graph/Applied Mathematics. A member of the first groups says: "What are you talking about? There is no difference!" A member of the other group might say: "Why don't you see it?"

I do not want to convince you to adopt anything, but I do want you to accept that the difference property/relation is made by others. You cannot deny that ER or (UML) class models exist and they distinguish between membership and association. I think that accepting this fact is the necessary condition for bridging PG and RDF. This is the topic of this thread, is it not ? If you 'simply decide not to use the property stuff of the PG' (to cite @HughGlaser) than you are not supporting PG! I also think that RDF must do something here because it provides the more general/abstract graph style.

So, I rephrase the question of @HughGlaser and @dbooth-boston:

IF you accept the difference between relation/property THEN how do you distinguish them?

Well, this is a very good question and the discussion can be extremly deep if not confusing (for example: intrinsic versus extrinsic properties). This is not the right place for such a discussion. Putting all philosophical questions aside I think finally it is choice that made by the guys who create the model. (Whether or not it is a bad thing to have this choice is again another question!)

I would list following general rules:

  • We must distinguish three things: properties/relations and those things which are related and own properties. The best name of these things is in my opinion entity (like in the ER model). An entity is a thing we talk about, it is the object of the model. A necessary condition is that an entity has an identity (otherwise it could not a be thing we talk about). But this is not sufficient because there are things that have an identity but can be regarded as property (value), like an email address. It follows that 'entity' is a stronger term than RDF's 'resource'.

  • A relation is a relation in the mathematical sense between entities (an n-ary logical predicate r(x,y,z...), where x,y,z... are entities). Putting higher relations aside (this is again again another question) a 'relation' is a binary ordered (directed) relation of two entities.

  • A property does not have an existence or identity by its own, it is always owned by an entity. If the entity is destroyed, all owend properties are also destroyed. A property can have any complex value, it is not restricted to be a single string literal. It can be an URI, a structure or sub-graph.

  • A property cannot be related to something, only its owning entity.

@namedgraph : I am sorry, but RDF is not what you are showing. RDF is a labeled directed graph plus three nodes types: IRI, Blank and Literal. There is a restriction that limits Literals to be leave nodes. This additional feature changes the graph completly. If you define a owl:DatatypeProperty it says that the object-node of an RDF statement shall be a Literal (please correct me if I am wrong here). I believe, we agree that Literals are properties in the PG sense (I said this several times). But what about IRIs and Blanks? Can they be interpreted as properties in the PG sense? Can a whole sub-graph be a property value in the PG sense? So owl:DatatypeProperty and owl:ObjectProperty do not help here.

draggett

comment created time in 2 days

startedsrp33/ShinyLearner

started time in 2 days

startedever-co/ever-traduora

started time in 2 days

fork hudochenkov/npm-upgrade

Interactive CLI utility to easily update outdated NPM dependencies

fork in 2 days

startedgzuidhof/starboard-cli

started time in 2 days

startedgzuidhof/starboard-notebook

started time in 2 days