Clarify Agent class hierarchy/definitions

[anarchivist]

Known classes of agents needed, with current definitions:

Class	Current class definition	Subclass of	Notes/known issues
Person	foaf:Person	foaf:Agent
Organization	foaf:Organization	foaf:Agent
Group	foaf:Group	foaf:Agent	Proposed usage of acl:agentGroup (see FCREPO-2275) has range vcard:Group
Software Agent	none	none	No class defined

Proposals:

• 1) Use prov:SoftwareAgent for Software Agent
• 2) Define hybox:SoftwareAgent (see detail here)

Questions:

• [x] foaf:Group or vcard:Group? 😞
• [ ] Do we need to define a class hierarchy like the following?

@prefix ex: <http://hybox.info/example/ns#>

ex:Agent a rdfs:Class ;
    rdfs:label "Agent" ;
    rdfs:subclassOf foaf:Agent, prov:Agent .

ex:Person a rdfs:Class ;
    rdfs:label "Person" ;
    rdfs:subClassOf ex:Agent, foaf:Person, prov:Person .

ex:Group a rdfs:Class ;
    rdfs:label "Group" ;
    rdfs:subClassOf ex:Agent, foaf:Group, vcard:Group .

ex:SoftwareAgent a rdfs:Class ;
    rdfs:label "Software Agent";
    rdfs:subClassOf ex:Agent, prov:SoftwareAgent .

[anarchivist]

Counter proposal from discussion with @cmh2166:

• Keep foaf:Agent/foaf:Group/foaf:Organization as is.
• Use of acl:agentGroup as fine as its range only entails that its subject <> is <> a vcard:Group .
• Add ex:SoftwareAgent as follows:

ex:SoftwareAgent a rdfs:Class ;
    rdfs:label "Software Agent" ;
    rdfs:subClassOf foaf:Agent  ;
    owl:equivalentClass prov:SoftwareAgent .

[cmharlow]

pros of option 1:

• gives skeleton where we can add more information if we vary in semantics/use of those classes
• any hydra developers looking to build functionalities that rely on certain predicates with range declarations can query for those specific range declarations + see what it effects (guess the alternate to this is they check specification or documentation for requested functionalities to know what classes should be effected if not those explicit in predicate range declarations)
• declaring equivalences or subclassing of hybox namespace classes to external classes gives us (through inference) shared understanding of these local classes, ability to query for multiple types and get same resources (where we think they should be)

cons of option 1:

• requires hybox to maintain that namespace for models
• not seeing any immediate use cases for defining hybox agents (besides software) and differently from external namespaces, so added complexity for little gain?
• last pro point, above, presumes inferencing of editors?

pros of option 2:

• just define/manage in hybox namespace new classes where we want to make new assertions (i.e. we want to use software, but can't just declare prov:Software to be subclass of foaf:Agent, our preferred Agent class for reuse, so creating hybox namespace class for this cross-pollination).

cons of option 2:

• basically don't get what we could have with option 1 pros.

Also, is this assuming that Hydra system Users & instance data metadata Agents are both using this model (which is a goal I think)? So Agents that work with WebACL but also are Agents as RWOs upon which we can associated Authorities, indicate at technical metadata creators (software), descriptive metadata Agents (authors, publishers, etc)?

[anarchivist]

Also, is this assuming that Hydra system Users & instance data metadata Agents are both using this model (which is a goal I think)?

Yes.

So Agents that work with WebACL but also are Agents as RWOs upon which we can associated Authorities, indicate at technical metadata creators (software), descriptive metadata Agents (authors, publishers, etc)?

They can, yes.

Based on these options I'm leaning towards option 2.