AgentType LOD implementation

[fosterlynn]

Taking this off of #9 and #11 , hoping we can come to a relatively focused decision, keep chipping away. (At least for this stage to move forward with.)

Two views have been expressed:

1. @elf-pavlik I think (according to his examples) would rather use foaf:Agent, foaf:Person, etc., and further subclass for agent types not already defined in vocabs. Examples that have come up: Community, POD, Network.
2. @ahdinosaur has expressed the perspective of doing what will fit our needs as a priority, and sees that as creating a new AgentType class I believe. I added on to that a property so that we know if the AgentType is a Person or Organization, for which we would use existing classes.

Everyone please correct me if I am mis-representing!

Proposal: We do 1., the subclassing method for this one. (Not the same solution for RelationshipType or other questions of types.) Choose the best existing classes, and define new subclasses in some namespace(s). The namespace might be openvocab, or might be more specific if we have user defined types.

So it would be something like this (citation @elf-pavlik ):

  "@id": "ex:openvocab/agenttypes/network",
  "@type": "rdfs:Class",
  "rdfs:subClassOf": "foaf:Group",
  "rdfs:label": {
    "en": "Network"
  },

Besides being more "standard", I think this is actually cleaner than defining AgentTypes and having to reference if it is a person or organization. In other words, I agree with @ahdinosaur in principal about doing what we think is best, but in this case I like the subclassing anyway.

[fosterlynn]

In either case, we will need to decide what existing vocab(s) we want to tie in with. @elf-pavlik can help a lot on this, he is more in tune with the state of existing vocabs. See https://github.com/openvocab/agent/issues/9#issuecomment-136832024, and the comment right after.

I think we need: Agent, Person, Organization

Might want Group? Instead of Organization or as a looser variant of Organization?

I do have a question on how to approach this. What do we do with something like foaf:Agent, where the properties are off in another universe, basically related to an agent's online life rather than its agency in economic activity, for example? Why did ActivityStreams create a new Person and Organization? But they reference foaf and others in their context.... ? And I know there was a lot of discussion in the W3C social interest group that @elf-pavlik and I participate in.

So I want to make a reasonable decision, but also don't want to take forever. I assume we can adjust as things change.

[elf-pavlik]

In either case, we will need to decide what existing vocab(s) we want to tie in with. @elf-pavlik can help a lot on this, he is more in tune with the state of existing vocabs. See #9 (comment), and the comment right after.

:+1: VCard, FOAF, Org, Schema.org (for now picking whatever works from any of them and than participating in process of clarifying such choices with Social IG and Web Schemas groups.

Let's keep in mind possible future data migrations and further aliments via constructs like http://schema.org/supersededBy . I if you can't quickly find any satisfying match in existing vocabs, just create a new terms and stay ready to eventually supersede it with some more common term. See also: https://lists.w3.org/Archives/Public/public-socialweb/2015Aug/0099.html

I understand that we don't need any more AgentType (rdfs:Class) or agentType (rdf:Propery)? Making sub classes of foaf:Agent (or as:Actor) and using rdf:type (@type in JSON-LD) directly should cover all needed cases for his.

For 'RelationshipType' I can create page similar to Verbs owl:Class vs. rdf:Property and we can discuss it further having clear diagrams and while deciding taking into accounts modeling of direct relations , qualified relations and containers.

[fosterlynn]

@elf-pavlik Thanks for the recommendations! I'm looking at them. Questions:

Can we ignore properties of classes that don't make sense to this vocab, or if we use a class like FOAF:Agent, are all the properties that are defined for the class then valid for our vocab?

Can we mix and match? Like use FOAF:Agent with a property of Schema.org:name?

Can we change the hierarchies? Like do we need to use FOAF:Person because we want it to have Agent as a superclass, where say vCard does not have that construct?

[fosterlynn]

@elf-pavlik Actually, looking deeper into FOAF, I see there are properties that are not documented as belonging to a class, but it looks like you can actually use them that way. Like FOAF:nick or FOAF:name.

Is this correct? Or does this have to do with these properties having status of "testing"?

And thanks for your patience as we get more up to speed! :smile:

[ahdinosaur]

Proposal: We do 1., the subclassing method for this one. (Not the same solution for RelationshipType or other questions of types.) Choose the best existing classes, and define new subclasses in some namespace(s). The namespace might be openvocab, or might be more specific if we have user defined types.

:+1:. keen to hop on board the RDF train with respective to our LOD vocab and see where we go. :train2: kudos to @elf-pavlik for enlightening us on how to do AgentType / RelationshipType models with RDF [0] [1].

[fosterlynn]

Status update: I'm in process of implementing a tentative JSON-LD output for agent stuff from NRP. Still a lot to do, but I have minimal output. Will publish out for your feedback when it is more or less working. And continue to update it with ongoing decisions on the vocab.

@elf-pavlik I am re-reading some of the Working Ontologist, getting more out of it this time through. Will need to do again later, I'm sure. :smile:

@ahdinosaur I'm hoping you might be interested in using this to feed Holodex, although I'm still happy to do csv output too. Will wait for that until you get the simpler model working inside Holodex.

[elf-pavlik]

Can we ignore properties of classes that don't make sense to this vocab, or if we use a class like FOAF:Agent, are all the properties that are defined for the class then valid for our vocab?

Can we mix and match? Like use FOAF:Agent with a property of Schema.org:name?

@fosterlynn properties 'belong' to class in Object Oriented Programming but NOT in RDF(S)/OWL !!!

http://www.hydra-cg.com/spec/latest/core/#documenting-a-web-api

In Linked Data, properties are, just as everything else, identified by IRIs and thus have global scope which implies that they have independent semantics. In contrast, properties in data models as used in common programming languages are class-dependent. Their semantics depend on the class they belong to. In data models classes are typically described by the properties they expose whereas in Linked Data properties define to which classes they belong. If no class is specified, it is assumed that a property may apply to every class.

These differences have interesting consequences. For example, the commonly asked question of which properties can be applied to an instance of a specific class can typically not be answered for Linked Data. Strictly speaking, any property which is not explicitly forbidden could be applied. This stems from the fact that Linked Data works under an open-world assumption whereas data models used by programmers typically work under a closed-world assumption. The difference is that when a closed world is assumed, everything that is not known to be true is false or vice-versa. With an open-world assumption the failure to derive a fact does not automatically imply the opposite; it embraces the fact that the knowledge is incomplete.

[fosterlynn]

properties 'belong' to class in Object Oriented Programming but NOT in RDF(S)/OWL !!!

@elf-pavlik Yes, starting to get that, I'm almost there with you! So the properties are defined by themselves, and then they can be assigned to a class (or more than one class) if you want. And the vocab can define that if you use that property, you are saying it implies that class, if you want, or not.

Where I have trouble is if I look at the properties foaf assigned to let's say Agent, I say to myself, that's not really the agent I'm thinking of, although it resembles it. But I can get to where I think that is OK, I don't have to use any of those properties. And what they historically mean by Agent is kind of mish-mashed anyhow, and I can accept that as part of the wild wild web and the way things tend to develop over time when there are a lot of people involved.

So I think I am getting much more willing to use the existing vocabularies without cringing and wondering if doing that will be completely confusing. And you have been very helpful! :smile:

[elf-pavlik]

And the vocab can define that if you use that property, you are saying it implies that class, if you want, or not.

Only if one uses RDFS reasoner it can infer additional statements based on domain and range of properties. http://www.w3.org/TR/rdf-schema/#ch_properties

BTW I find explanations of all those nuances in Working Ontologist book very helpful!

[fosterlynn]

BTW I find explanations of all those nuances in Working Ontologist book very helpful!

Me too. But I can only understand so much at a time, need to go back thru it every so often....

[elf-pavlik]

@fosterlynn please let me recognize here your rapidly growing understanding of various nuances of Linked Data modeling! :smile: I think we all could use some clear reference in lines of "Linked Data for people with background in Object Oriented Programming" #TODO

[bhaugen]

I think we all could use some clear reference in lines of "Linked Data for people with background in Object Oriented Programming" #TODO

+1000

[fosterlynn]

@elf-pavlik well, it is worse than that.... what about those of us who are so old we started with spaghetti code on punch cards reading and writing to un-indexed files, had to learn structured code and modularity, then relational databases, then OOP. Then there's my much older sister, who started with programming by wiring boards...

[fosterlynn]

Is everyone OK with the following?

foaf:Agent foaf:Person foaf:Organization foaf:Group

Does anyone prefer org:Organization?

[ahdinosaur]

i'm skeptical about using foaf agent types. i wonder what we gain with that approach over using our own vf:Agent and derivatives that follow our own standards (e.g. how we handle labels, how we do subclassing, how we do multilingual properties, etc), as our own agent types can still reference existing types (foaf, as, schema.org, org, ...). personally as someone who wants to consume this vocab, it seems better for all the agent types to be consistent to our standard instead of having special cases for the base agent types.

[elf-pavlik]

@fosterlynn Let's give ourselves little more time in a comfort of defining everything the way we wish to use it. Once we have few more concrete examples, plus working services and apps using those examples, we can pick up discussion about reusing existing vocabularies. This way we will see if this change breaks something, or really makes things harder.

[fosterlynn]

@elf-pavlik I honestly don't know which is the best approach, not having done this before, so I am happy to take your guidance. But then don't we need to go ahead and define our own vocab terms, including the subclassing, domain, range, etc.? I would like to get the whole thing working with at least the correct architecture, i.e. pulling our context from where it lives. I suppose we could look at it as a useful learning exercise to define our own. :smile:

I do find it pretty annoying that many vocabs continue to define their own version of the same thing, like Person. Or is there a good reason for this that I'm missing? (I know you are not suggesting that, just suggesting a different order of development.)

Also, I think I finally understood that we can use someone's vocab for a class (say Agent) without committing to their properties, so we could supply our own properties to an existing class. Is this a correct understanding?

[elf-pavlik]

Also, I think I finally understood that we can use someone's vocab for a class (say Agent) without committing to their properties, so we could supply our own properties to an existing class. Is this a correct understanding?

Yes! I would even say:

"we can define new properties ourself, and recommend using them on various existing classes"

Since rdf:Property doesn't stay 'inside' owl:Class and has its full autonomy! Actually properties define their relationships to classes (eg. rdfs:domain and rdfs:range) and I can't really think of example where class would define relationship to some properties.

[bhaugen]

@elf-pavlik - is that the distinction you were trying to make to me once upon a time? That properties define their relationships to classes via domain and range, rather than classes defining their relationships with properties? If so, thanks, that's a clear and concise explanation, and pretty much what I had gathered from reading several much more verbose and winding articles. But this makes it sink in much better.

[elf-pavlik]

thanks for feedback @bhaugen, I'll just start collecting such notes in https://github.com/hackers4peace/rdf-for-object-oriented-heads

[almereyda]

We have moved the ValueFlows organization from GitHub to https://lab.allmende.io/valueflows.

This issue has been closed here, and all further discussion on this issue can be done at

https://lab.allmende.io/valueflows/agent/-/issues/15.

If you have not done so, you are very welcome to register at https://lab.allmende.io and join the ValueFlows organization there.