search

valueflows / agent

agent has moved to https://lab.allmende.io/valueflows/agent
10 stars 4 forks source link

foaf labels, removed member #66

Closed fosterlynn closed 8 years ago

fosterlynn commented 8 years ago

THIS IS FOR DISCUSSION, NOT TO MERGE YET. Ref. https://github..com/valueflows/agent/issues/65.

I implemented the changes suggested that I knew how to do.

I had added org:Organization a long time ago in the diagram source, can remove if anyone still objects.

I don't really know how to represent the member stuff in this kind of hybrid model, so I took it off for now. I would not put something like rdf:Property in a UML model in the UML world, it is more like a type than a representation of functional content. But I don't know what is really the most helpful here. I think most UML models in the LOD world that I have seen stick to functional entities. Seeking the right balance....

elf-pavlik commented 8 years ago

I would prefer to remove org:Organization for now and see where we will get with just foaf:Person and foaf:Group.

Following http://xmlns.com/foaf/spec/#term_member

You can just add an arrow pointing from foaf:Group to foaf:Agent with label member

fosterlynn commented 8 years ago

You can just add an arrow pointing from foaf:Group to foaf:Agent with label member

The trouble is that the relationship is already there in the model, the subject-relationship-object, so repeating it in a totally different place is not correct. So I'm not sure how to model it. I think the rdf:Property is causing some of the trouble since it is a UML diagram. Maybe I'll try to re-work it to be less LOD dependent?

I would prefer to remove org:Organization for now and see where we will get with just foaf:Person and foaf:Group.

We have tons of data in NRP where people need Organization. And an Organization is not necessarily a Group, as explained before, like my old consulting company of one person. We may not like many Organizations, but they do exist and they do have agency, and people we do like need to refer to them. http://xmlns.com/foaf/spec/#term_Organization is the same structure. So, I will remove it if we don't have agreement, but I'd like to understand exactly what is your objection?

elf-pavlik commented 8 years ago

The trouble is that the relationship is already there in the model, the subject-relationship-object, so repeating it in a totally different place is not correct.

We have binary and n-ary version of relationship. Many people will use just binary version and we can't assume that everyone will use the n-ary version. Also for 'member' relationship I don't think anyone will have reason to use the n-ary version, since currently it only allows to qualify the relationship with vf:context.

We have tons of data in NRP where people need Organization. And an Organization is not necessarily a Group, as explained before, like my old consulting company of one person.

In that case one can just use most generic foaf:Agent. Nothing also forbids foaf:Group with only one member.

So, I will remove it if we don't have agreement, but I'd like to understand exactly what is your objection?

I think we need to carefully looks how to recommend use of org: ontology and understand well its alignment with foaf:. It also has both member and subOrganization relations, which we should take a closer look at before recommending its use.

fosterlynn commented 8 years ago

I think we need to carefully looks how to recommend use of org: ontology and understand well its alignment with foaf:. It also has both member and subOrganization relations, which we should take a closer look at before recommending its use.

OK, how about we just use foaf:Organization? I agree there are lots of parts of the org model we don't want to use, it is very enterprise / corporate. And if I recall, their model of member won't really work for us. But foaf:Organization is fine with me.

I'm going to add this as a general topic for next meeting, would be good to understand how we want to relate to other vocabs when we just like parts of them.

fosterlynn commented 8 years ago

Also for 'member' relationship I don't think anyone will have reason to use the n-ary version, since currently it only allows to qualify the relationship with vf:context.

Well, there were other properties we never got figured out, like dates or states. Hmmm, maybe we ought to go back and fill some of those in at some point....

elf-pavlik commented 8 years ago

Maybe let's than look at org: ontology sooner than later https://www.w3.org/TR/vocab-org/#class-membership

fosterlynn commented 8 years ago

Maybe let's than look at org: ontology sooner than later https://www.w3.org/TR/vocab-org/#class-membership

Their membership is too narrow, just deals with Organization. And is modeled in a sort of limited way. And we need user defined relationship types. I was only interested in org:Organization, and I just thought their model was more developed and used than foaf - and I could be wrong on that. I'm not tied to it at all. I am interested in getting the Organization concept in there though so people don't have to put it in themselves.

ahdinosaur commented 8 years ago

And an Organization is not necessarily a Group, as explained before, like my old consulting company of one person.

ahh, vf:Organization makes sense meow! :+1:

elf-pavlik commented 8 years ago

I created #65 as bug report since current UML has some very inaccurate information.

@fosterlynn could you in this PR only address that issue and create dedicated PR with atomic proposal for organization? I see couple of things to clarify there and I don't think we should bundle it together with simple bug fix.

I will copy this questions to that new PR

fosterlynn commented 8 years ago

Closing this because I can't figure out how to add a commit with the new picture. Will open a new PR and a new issue to discuss vf:Organization.