search

valueflows / agent

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

add AgentType to context #49

Closed ahdinosaur closed 8 years ago

elf-pavlik commented 8 years ago

:-1: while I understand it currently may make it more convenient for you to think about things, many people familiar with linked data vocabularies may find it simply confusing

I don't say we should never introduce such alias, but can we still wait with such proposals little longer? once we gather more .jsonld examples and develop more shared understanding among ourselves (in all the directions of course!)

ahdinosaur commented 8 years ago

many people familiar with linked data vocabularies may find it simply confusing

true, but then again who is our intended audience for this project? most people i've had conversations with about Value Flows find 'semantic web' linked data vocabularies to be confusing.

elf-pavlik commented 8 years ago

I would like that we first document well usage of terms like type, class, kind, category or whatever we come up with...

Will we always use instances of FooType* as values of JSON-LD "@type", same as rdf:type?

ahdinosaur commented 8 years ago

Will we always use instances of FooType* as values of JSON-LD "@type", same as rdf:type?

based on the data model of our prototype app, plus the claimed success from @bhaugen and @fosterlynn on how well this 'type object pattern' works for them, i think yes?

not in a rush to get this in though.

elf-pavlik commented 8 years ago

cool! let's than let it simmer here for a while and don't rush to go this way...

elf-pavlik commented 8 years ago

we can keep this PR open, I see really no need to close it!

fosterlynn commented 8 years ago

@ahdinosaur @elf-pavlik I think on this one I would agree with elf, as long as we can subclass the existing Agent, Organization, Group, maybe even Person, as needed for network specific "vocabulary". I believe this gives the same feature and flexibility as AgentType. In object/relational land (where NRP lives), we don't have the option of subclassing at runtime. But happy to keep it simmering now too, I think we'll collectively have more clarity after our next meeting too....

ahdinosaur commented 8 years ago

as long as we can subclass the existing Agent, Organization, Group, maybe even Person, as needed for network specific "vocabulary". I believe this gives the same feature and flexibility as AgentType.

this pull request is only meant to make an alias from AgentType to owl:Class, as used in my most recent example.

elf-pavlik commented 8 years ago

@ahdinosaur after thinking about what you propose here little more, I really have impression that we need to work out differences between RDF and OOP. You propose defining two different instances of owl:Class:

If we look at both as defining a set of entities and assertions below, carry a meaning

Why do you prefer it from definitions based on rdfs:subClassOf ? Where you can find all known members of vf:AgentType set, which you propose explicitly defining here, by collecting in recursive way all rdfs:subClassOf vf:Agent.

   {
        "@id": "Person",
        "@type": "AgentType",
        "rdfs:label": {
            "en": "Person"
        },
        "rdfs:subClassOf": {
            "@id": "Agent"
        }
    }

In my opinion above tries to define a person as rdfs:Class (type of things) and a sub set of vf:Agent using two different constructs at the same time. Could you please point us to a particular use case, where you need this additional construct and can't rely on commonly used rdfs:subClassOf definitions?

elf-pavlik commented 8 years ago

Please also notice your enspiral example in JSON-LD Playground http://tinyurl.com/nawywqd

[
  {
      "@id": "dex:resourceTypes/company",
      "@type": "AgentType",
      "labelMap": {
        "en": "Company"
      }
    },
    {
      "@id": "dex:resourceTypes/brand",
      "@type": "AgentType",
      "labelMap": {
        "en": "Brand"
      }
    }
]

Did you surprise yourself with this result of JSON-LD expansion and compaction?

I recommend trying, good old (and reliable)

{
    "@id": "dex:resourceTypes/company",
    "@type": "owl:Class",
    "rdfs:subClassOf": "vf:Resrouce",
    "label": "Company"
  }
bhaugen commented 8 years ago

@elf-pavlik - I think this is my fault (coming from NRP), not @ahdinosaur's. It is not really OOP vs RDF. In classical OOP, Agent can have subclasses Person and Group.

In NRP, we make generous use of the Type Object pattern. So those type objects (AgentType, RelationshipType, EventType, etc) were included in the vocab we originally posted at the beginning of the ValueFlows project.

I'll wait for @fosterlynn to respond before getting any deeper into this issue, but did want to absolve @ahdinosaur of any blame here.

elf-pavlik commented 8 years ago

From Type Object Pattern pdf

The advantages of the Type Object pattern are:

  • Runtime class creation. The pattern allows new "classes" to be created at runtime. These new classes are not actually classes, they are instances called TypeObjects that are created by the TypeClass just like any instance is created by its class. ...

IMO above applies to OOP but I don't see its relevance to RDF. At the same time, nothing we do here should prevent someone from taking advantage of Type Object Pattern in particular implementation in some OOP language. People using functional languages will most likely also use some other common patterns, when using this vocab in their runtimes.

I also have no intention of blaming anyone, just trying to understand what this proposal tries to accomplish, and myself propose considering possible other patterns to meet the same requirements.

bhaugen commented 8 years ago

I'm not arguing for using it, just explaining where it came from. Totally usable before and after OOP. For example, very handy to work around some of the limitations of relational databases. Might not be relevant to RDF, I'm still not deep enough to know.

fosterlynn commented 8 years ago

As I said above, I don't think we need the AgentType class or any aliasing to get what we want. We should just use Agent and its subclasses, and that makes the types. No need for the Type Object pattern, subclassing substitutes for that. One would want to one or the other, but not both.

Too change elf's example to get it out of resource land for the moment, and with apologies if the example isn't real:

{
    "@id": "dex:agentTypes/pod",
    "@type": "owl:Class",
    "rdfs:subClassOf": "vf:Group",
    "label": "Pod"
  }

@ahdinosaur does this make sense?

ahdinosaur commented 8 years ago

@elf-pavlik cool, to recap my understanding:

no objections to that here. the only proposal i can imagine now is if we wanted a generic Type (based on both owl:Class and skos:Concept) to keep our types consistent in our namespace (and less characters to type).

@fosterlynn yep, your example makes sense. :)

No need for the Type Object pattern, subclassing substitutes for that. One would want to one or the other, but not both.

but your example is both. :p the "type" is an object with @type owl:Class, which can subclass other types. now that i'm starting to better understand the RDF / JSON-LD flavor of OOP, i do think it supports the Type Object pattern quite well, as demonstrated.

elf-pavlik commented 8 years ago
  • creating an alias is not great if it could overlap with other aliases

If you make two aliases for the same URI, after JSON-LD expansion you don't know any more which alias compacted version used. This doesn't work if intend to capture some information, for example distinguish two different types of entities.

  • asking for all the *Types is asking for all subclasses of the base Type (e.g. asking for all types of agent is asking for all subclasses of vf:Agent)

In recursive way, all members of a set defined as rdf:subClassOf some other set, also stay member of this other (parent) set. Same with defining another rdf:subClassOf of the (child) set, all its members still say included in 'top most' (grandparent) set.

Something to always keep in mind, each instance can have assertions of belonging to any number of sets "@type": [ "vf:Resource", "schema:Book", "foo:Novel", "gr:Product" ] etc. So one would never in code check thing["@type"] === helper.expand("schema:Book") but always assume that it can have any number of types (even 50 or 100, especially if it has materialized inferences) and instead always check thing["@type"].includes(helper.expand("schema:Book")). Most likely libraries specific to different programming languages, define nicer idiomatic interfaces and don't hack directly around how they represent raw JSON structures in their runtime.

bhaugen commented 8 years ago

Materialize inferences are an interesting idea. I think I like...bookmarked for future ref.

elf-pavlik commented 8 years ago

@ahdinosaur I propose closing this PR without merging and updating enspiral.jsonld to use rdf:subClassOf based on https://github.com/valueflows/agent/pull/49#issuecomment-149851072