proposal: use rdf:Property instead of rdfs:Class for AgentType

[ahdinosaur]

i'm not fully aware of the semantics of rdf:Property vs rdfs:Class, but we're using one for one type (Class -> AgentType) and one for the other type (Property -> RelationshipType). what's the pros and cons of each?

as a strike against Class, i'm wary of a @type that's not one of the {Agent,Relationship}{,Type} symbols. it seems much simpler if @type is always the name of the vocab.

what if AgentType was a Property, so we reference to it like RelationshipType?

[fosterlynn]

I've been tentatively thinking for AgentTypes, we use foaf:Agent, foaf:Person, foaf:Organization (this one I'm not sure it is the best). Also could use foaf:Group, that might suit people's thinking better for looser organizations. But in any case, we start with an existing hierarchy like this one. Then when a network defines other agent types, we subclass foaf:Person, foaf:Organization, or foaf:Group, or maybe foaf:Agent (or whichever existing hierarchy we decide to use).

This works for us because we both have a need for user defined agent types and a need to know if it is a person or not.

AgentType doesn't strike me as a property, but this is only gut at this point, and somewhat based on looking at existing vocabs.

@ahdinosaur what do you think of the subclassing scheme?

[ahdinosaur]

hmm, that subclassing scheme is what i was originally thinking, this was just a new thought. what makes RelationshipType more like a Property than AgentType? for the implementation, it seems weird to handle two cases of the same type object pattern, but that's only a feeling.

[fosterlynn]

Thinking more about this question - I don't really know why theoretically to think about agent types as classes and relationship types as properties. In our model, we have other properties related to both. And in our more familiar OOP paradigm, you can't really group properties except through a class, so we started out with both being a class.

But it does seem like that difference is pretty consistent in the existing LOD vocabularies. I just did a bit of a survey of the big vocabs, and that is how people do think of it.

Actually the reason behind this might be that everything relates back to RDF triples, subject-predicate-object. And agents would be either subjects or objects, while relationships would be predicates, which tend to be verbs or roles. Subjects and objects tend to be nouns. (I could be wrong about this being the reason.)

In this case, I think I would be for sticking with the dominant LOD thinking, so we fit better with existing vocabs, and assuming that we don't know enough yet to deviate. So this would make agent types subclasses and relationship types properties.

The only open question in my mind there is that we lose the metadata aspect (the vocab definition) on relationship types by making it a property instead of a class. We can group properties together ( @elf-pavlik showed us how), but we can't define that they should be grouped together. I think. Could be wrong. But I'm still for going with the LOD flow at this point.

[fosterlynn]

@ahdinosaur Continuing to explore other contexts, am seeing one example where the relationship type IS a class! This is in vcard. Here is the super class, Relation Type: http://www.w3.org/TR/vcard-rdf/#d4e2246. Has a bunch of subclasses.

Still assessing, but wanted to get this out here as an exception to my last post.

[elf-pavlik]

Let's try to keep in mind Direced Graph model (Labeled directed graph in case of RDF). We have nodes and edges with labels. In most cases instances of rdf:Property get used for labels of an edge. Eg.

:elfpavlik foaf:knows :fosterlynn
:openvocab schema:member :elfpavlik

@ahdinosaur do you have any case where you would use type of an agent as a label for an edge between two nodes?

The only open question in my mind there is that we lose the metadata aspect (the vocab definition) on relationship types by making it a property instead of a class.

@fosterlynn to my understanding @ahdinosaur currently uses slightly modified http://json-schema.org/ - technology not meant to describe Linked Data vocabularies!

Data Shapes WG currently works on technologies which can provide constructs similar to ones in JSON Schema but designed for RDF (graph structure), not JSON (tree structure unless JSON-LD used)

[fosterlynn]

@elf-pavlik Very good point about the directed graphs, makes sense to me, re. what is classes and what is properties.

No, I'm not considering @ahdinosaur 's notation from before - you aren't either, are you Mikey?

I'm working on the context as we speak, will publish when I get something done, and look forward to lots of feedback!

[ahdinosaur]

Actually the reason behind this might be that everything relates back to RDF triples, subject-predicate-object. And agents would be either subjects or objects, while relationships would be predicates, which tend to be verbs or roles. Subjects and objects tend to be nouns. (I could be wrong about this being the reason.)

We have nodes and edges with labels. In most cases instances of rdf:Property get used for labels of an edge.

yeah, this makes sense now.

@ahdinosaur do you have any case where you would use type of an agent as a label for an edge between two nodes?

nah. the reason i introduced this issue was because i find the semantics around @type to be confusing (you have to think about it differently depending on whether it's a class or property) and was wondering if it was possible to make it more consistent. now i understand that it's not a good idea, at least the difference is there for a reason.

No, I'm not considering @ahdinosaur 's notation from before - you aren't either, are you Mikey?

haha, i sure am, i'm still using it presently for this project. :smile: @elf-pavlik happy to use another notation but this is the best way of describing Linked Data vocabularies i could find. (needs to be enough to generate a client, a daemon, and bonus points if it can generate some CRUD forms).