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

Connection is now modeled as an Activity, should we model is as a reified statement? #99

Closed
jasnell opened this issue Apr 14, 2015 · 6 comments

Comments

@jasnell
Copy link
Collaborator

jasnell commented Apr 14, 2015

e.g.
{
"@type": "Connection",
"a": "acct:john@example.org",
"predicate": "foaf:knows",
"b": "acct:sally@example.org"
}

where a and b are subproperties of rdf:subject and rdf:object and predicate is a subproperty of rdf:predicate. This allows us to easily reuse other existing vocabularies for describing relationship types.

@elf-pavlik
Copy link
Member

@jasnell please take a look at diagrams I just did around reification, relations, qualified relations and activities

social vocab
original drawings

@rhiaro

@jasnell
Copy link
Collaborator Author

jasnell commented Apr 14, 2015

@elf-pavlik that doesn't actually help address the question. On the call today it was decided to remodel the existing "Connect" and "FriendRequest" Activity types into a "Connection" object. That Connection object has to be able to describe a connection between two individuals. Such an object is naturally a form of reified statement. The question is only if we want to formally model it as such.

@elf-pavlik
Copy link
Member

I think we do want to use reified statements and reuse predicates. It will also come handy when we query. Since systems can have both qualified and non qualified relations in used dataset.

@prefix : <https://example.vocab/>
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix foo: <http://example.foo/> .

:QualifiedRelation a owl:Class .

:Connection a owl:Class ;
  rdfs:subClassOf rdf:Statement ;
  rdfs:subClassOf :QualifiedRelation .

:Following a owl:Class ;
  rdfs:subClassOf :Connection .

foo:elf-pavlik a :Person .
foo:jasnell a :Person .

foo:elf-pavlik-followed-jasnell a as:Follow ;
  as:actor foo:elf-avlik ;
  as:object foo:jasnell ;
  as:result foo:elf-pavlik-following-jasnell .

#qualified relation
foo:elf-pavlik-following-jasnell a :Following ;
  rdf:predicate :follow ;
  rdf:subject foo:elf-avlik ;
  rdf:object foo:jasnell ;

# additional unqualified relation for ease of querying
#(most comnonly used in already existing data)
foo:elf-pavlik :follows :foo:jasnell .

Please also notice :Following as result of :Follow #94

@elf-pavlik
Copy link
Member

I also started similar diagrams for Container #82 which also uses pattern similar to reification. I use ldp:DirectContainer and this way again we can reuse same predicates to follow our nose to containers with people i follow or who follow me 😄

  • people who follow me - start from me and follow ldp:membershipResource in reverse direction to containers and choose one with ldp:isMemberRelation: :follows
  • people who I follow - start from me and follow ldp:membershipResource in reverse direction to containers and choose one with ldp:hasMemberRelation - :follows

containers
original drawings

@elf-pavlik
Copy link
Member

I also suggest reading Defining N-ary Relations on the Semantic Web

Use Case 3 of N-ary Relation looks very much like as:Activity
N-ary relation with no distinguished participant
http://www.w3.org/TR/swbp-n-aryRelations/#useCase3

@elf-pavlik
Copy link
Member

While working on Travel with actor staying multiple times in the same city. I found need that a qualified relation links to relevant activities which provide more detailed timeline. Similar can happen with Connection to another agent. I can Follow/Unfollow, Friend/Unfriend etc. multiple times. So Qualified Relation(s) between two agents serve distinct purpose than Activitiy(ies) which happen between them. I don't see question "should we use one or the other?" a proper one here. Instead I think both have its place and we just need to clearly define and explain how one relates to the other...

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

No branches or pull requests

3 participants