Examples, updated context, readme draft

[fosterlynn]

Bob and Lynn related to Mikorizal and Sensorica example. Rough draft of readme as start to human readable doc on the vocab. Added to context based on new example.

Question: Do you think all the examples should be broken out, and if so, to what level? For example, where would you put relationships? Or is this OK?

[elf-pavlik]

@fosterlynn I would like to leave out fooType pattern until we evaluate it, compare to rdfs:subClassOf and agree on which one we use (or both).

[ahdinosaur]

@elf-pavlik: @fosterlynn I would like to leave out fooType pattern until we evaluate it, compare to rdfs:subClassOf and agree on which one we use (or both).

can you unpack this?

i thought we reached consensus on this:

• AgentType object
  • is @type rdf:Class
  • subtyped with rdfs:subClassOf
• Agent object
  • references AgentType object with @type
• RelationshipType object
  • is @type rdf:Property
  • subtyped with rdfs:subPropertyOf
• Relationship object
  • references Relationship object with as:relationship
  • references related Agent objects with as:subject, as:object, as:context

[fosterlynn]

@elf-pavlik: @fosterlynn I would like to leave out fooType pattern until we evaluate it, compare to rdfs:subClassOf and agree on which one we use (or both).

can you unpack this?

@ahdinosaur I think this is referring to my picture, which is meant to be conceptual, so still has the Relationship Type in it because I couldn't figure out how else to represent that grouping of properties.

The same thing is happening in your statement of what we agreed on, like conceptually there is a RelationshipType object, but it is not implemented that way, it is just a rdf:Property so you would never see the vocab term RelationshipType I don't think. Same with AgentType, you would not see that as a vocab term. Am I thinking of this the way you all are?

And we're still discussing that on in the good ol' issue #38 too.

[elf-pavlik]

RelationshipType object is @type rdf:Property subtyped with rdfs:subPropertyOf

:+1: I thought merging it implies removing my objection

AgentType object is @type rdf:Class subtyped with rdfs:subClassOf Agent object references AgentType object with @type

Why not simply:

Agent object subtyped with rdfs:subClassOf

?

I really want to make sure that we don't confuse instances of rdf:Property (used mostly for labels of edges, but can also act as a node) with instances of rdfs:Class/owl:Class (used as values of rdf:type)

Once again this wiki page hopefully illustrates it https://github.com/w3c-social/social-vocab/wiki/Verbs---owl:Class-vs.-rdf:Property#proposed-alternative

@fosterlynn IMO did it properly so in the end I merged it...

I think we still need to work out naming... word type may suggest for many people Class, while for the value of 'relationshipType' we use instance of rdf:Property not instances of rdfs:Class/owl:Class.

How about s/relationshipType/relationshipProperty/ or even simply using for now vf:property seeing when we really need vf:relationshipProperty rdfs:subPropertyOf vf:property ?

[ahdinosaur]

:+1: I thought merging it implies removing my objection

@fosterlynn IMO did it properly so in the end I merged it...

yeah, my strategy is to merge by default, only block in exceptional cases, and for anything you want differently than what is merged to make subsequent issues / pull requests.

[ahdinosaur]

Why not simply:

Agent object subtyped with rdfs:subClassOf

?

what would be gain from this approach? for one, we'd lose the separation of our abstract type from the specific instance, which is a powerful pattern that attracted me to @bhaugen and @fosterlynn's work in the first place. unless i'm missing something.

I think we still need to work out naming... word type may suggest for many people Class, while for the value of 'relationshipType' we use instance of rdf:Property not instances of rdfs:Class/owl:Class.

How about s/relationshipType/relationshipProperty/ or even simply using for now vf:property seeing when we really need vf:relationshipProperty rdfs:subPropertyOf vf:property ?

the reason i like the word "type" is that it keep clarity with the pattern on which our vocab is based, the "type object pattern" (https://github.com/valueflows/valueflows/issues/8#issuecomment-66791770, https://github.com/valueflows/valueflows/issues/8#issuecomment-66873137). i prefer simple systems, so a single name for a single concept, whereas i find "property" or "class" to be confusing when they are the same concept (an abstract "type" of the specific instance) but applied to either edges or nodes, respectively.

couldn't we alias over the differences between rdfs:Class and rdf:Property anyways for each "type"? as in:

{
  "@context": {
    "AgentType": "rdfs:Class",
    "subAgentOf": "rdfs:subClassOf",
    "RelationshipType": "rdf:Property",
    "subRelationshipOf": "rdfs:subPropertyOf"
  }
}

or something.

that being said, there's an appeal to conforming closer to The RDF Way of Linked Open Data if we think that will benefit us, i just don't want our vocab to assume this is the only way to do Linked Open Data (see ssb for an alternative approach).

[ahdinosaur]

i prefer simple systems, so a single name for a single concept, whereas i find "property" or "class" to be confusing when they are the same concept (an abstract "type" of the specific instance) but applied to either edges or nodes, respectively.

btw, this is part of why i proposed to use rdf:Property instead of rdfs:Class for AgentType.

[elf-pavlik]

@ahdinosaur I have impression that we may mix data about vocab/schema customization used by certain dataset with the actual data which we create those extensible vocabs/schemas to express in machine readable way https://gitter.im/valueflows?at=561a21276dc64436714ac0f1

what would be gain from this approach? for one, we'd lose the separation of our abstract type from the specific instance, which is a powerful pattern that attracted me to @bhaugen and @fosterlynn's work in the first place. unless i'm missing something.

I see big importance in modeling Linked Data vocabularies to look for balance on which semantics (not human prefered labeling) we can agree on and which not. Currently with definition

 {
    "@id": "ex:Heyoka",
    "@type": ["rdfs:Class", "owl:Class"],
    "rdfs:label": {
        "en": "Heyoka"
    },
    "rdfs:subClassOf": "foaf:Person"
}

No all the systems on the web will understand various semantics specific for this particular 'kind' of a Person. Still all systems which know semantics of foaf:Person and support reasoning based on rdfs:subClassOf will know: "Heyoka means some specialization of foaf:Persona, we can also consider it foaf:Person which meaning we understand, but unless we understand meaning of this particular specialization we may miss certain level of more specific understanding"

By introducing something like vf:subAgentOf, you will force all the systems on the web, to either support this particular construct, or have no clue that what you try to define as particular specification of commonly recognized (understood) foaf:Person or foaf:Agent has any similarity to it, even that they implement commonly used constructs like rdfs:subClassOf.

For those reasons I would ask if you can provide concrete, real world example, which shows that you can not achieve something what you need using already commonly used pattern based on rdfs:subClassOf and common references like foaf:Person. And which currently you can only think of a way to implementing by introducing into the open environment of The Web completely new construct like vf:subAgentOf ?

[ahdinosaur]

@elf-pavlik

@ahdinosaur I have impression that we may mix data about vocab/schema customization used by certain dataset with the actual data which we create those extensible vocabs/schemas to express in machine readable way https://gitter.im/valueflows?at=561a21276dc64436714ac0f1

i guess i'm not seeing a problem with that, the intention is to make an abstract vocabulary that in order to use means defining specific vocabs for local semantics, it shouldn't matter if we mix these "types" with the "data", it's all data anyways.

And which currently you can only think of a way to implementing by introducing into the open environment of The Web completely new construct like vf:subAgentOf ?

i wasn't suggesting we add vf:subAgentOf, just to alias subAgentOf to rdfs:subClassOf. i mean really i'd prefer there be one way to inherit from any of our types, but it seems some of our types are rdf:Property and some are rdfs:Class and i don't like having to juggle multiple cases when i build systems.

[bhaugen]

I'll fork this into a separate issue, if that is ok: #44

[elf-pavlik]

it shouldn't matter if we mix these "types" with the "data", it's all data anyways.

while we may find benefit in agreeing to us 'age' property to assign number of years since someone's birth, we don't need to agree on when in particular we should all be born...

i wasn't suggesting we add vf:subAgentOf, just to alias subAgentOf to rdfs:subClassOf. i mean really i'd prefer there be one way to inherit from any of our types

what exactly do you try to 'inherit'? maybe you could show alternative to proposed by me above definition of ex:Heyoka?

[fosterlynn]

but it seems some of our types are rdf:Property and some are rdfs:Class and i don't like having to juggle multiple cases when i build systems.

@ahdinosaur I had that issue earlier, but I think I have let go of that. @elf-pavlik I think your explanation of rdfs:Class tends to be nodes and rdf:Property tends to be edges is helpful for me. Expecially since rdf:Property can exist without a class, and you can sub-property them.

I don't think that all of this has to affect how we think of our building our functional systems. I certainly don't intend to make any changes to AgentType or AgentAssociationType in NRP! I am finding that this is like when I had to make the transition from relational to OO modeling structures. And that impedance mismatch never went away, we just manage it in the interface between the OO structures in the code and the relational database. This will be similar, we just manage it when we translate OO (or relational) data to rdf and back.

[elf-pavlik]

@fosterlynn how do you use in NRP definitions of AgentType and AgentAssociationType shared across different instances and use them ther to describe data about particular agents and associations hosted on those instances?

[fosterlynn]

@elf-pavlik We don't have anything now that crosses instances, thus this vocab, hey!

We do have a type-type ("behavior") kind of field on both AgentType and AgentAssociationType that is common to all instances and could be used. We mostly use them to limit dropdowns in various situations, that kind of thing.

AgentType has a selection of Individual, Organization, Network, a few others that probably aren't needed there actually.

AgentAssociationType has a selection of member, customer, supplier, a few others. (Both customer and supplier because this is from the perspective of a network. But really probably we should combine them.)

So we could never actually hook up one harvester with another harvester, except just by name, and we don't know if they are the same thing. I think it goes back to your thoughts about how this evolves from here. If a couple networks want to interoperate, they have a reason to sync some of their vocabulary. This gradually grows until things are really vocabulary and can be standardized. I could see this happening in the food network arena, they are farther along in many ways.

[ahdinosaur]

@fosterlynn: @ahdinosaur I had that issue earlier, but I think I have let go of that. @elf-pavlik I think your explanation of rdfs:Class tends to be nodes and rdf:Property tends to be edges is helpful for me. Expecially since rdf:Property can exist without a class, and you can sub-property them.

yeah, i'm coming around to accepting rdfs:Class and rdf:Property as separate things, especially if

@elf-pavlik: How about s/relationshipType/relationshipProperty/ or even simply using for now vf:property seeing when we really need vf:relationshipProperty rdfs:subPropertyOf vf:property ?

means we generalize property, but anyways i'm letting it all slowly simmer into my back brain.

@fosterlynn: I don't think that all of this has to affect how we think of our building our functional systems. I certainly don't intend to make any changes to AgentType or AgentAssociationType in NRP! I am finding that this is like when I had to make the transition from relational to OO modeling structures. And that impedance mismatch never went away, we just manage it in the interface between the OO structures in the code and the relational database. This will be similar, we just manage it when we translate OO (or relational) data to rdf and back.

that's really good to hear. i think we'll do the same for Holodex, since these RDF changes are adding complexity that i'd rather keep out of our app codebase and defer to an external translation module, which also means we won't feel tied to The JSON-LD / RDF Way if a better way of doing linked open data arises (e.g. ssb).

[elf-pavlik]

since these RDF changes are adding complexity that i'd rather keep out of our app codebase and defer to an external translation module, which also means we won't feel tied to The JSON-LD / RDF Way if a better way of doing linked open data arises (e.g. ssb).

@ahdinosaur I would find it very helpful if you could document somewhere in what exact way you see approach here adds complexity? To my understanding holodex as of now doesn't work with data distributed across different dataspaces (domains) on the web, I would expect certain increase in complexity while adding support for that. When it comes to ssb it looks like it has no support for groups and access control, it also seems JSON specific which I would keep in mind while deciding to commit to depend on it.

[ahdinosaur]

@elf-pavlik: @ahdinosaur I would find it very helpful if you could document somewhere in what exact way you see approach here adds complexity? To my understanding holodex as of now doesn't work with data distributed across different dataspaces (domains) on the web, I would expect certain increase in complexity while adding support for that.

an id is a URL, so that's enough to handle data distributed across domains, assuming each domain provides the data in the proper format. anything more than a single state object exactly as the Holodex user interface code expects is additional complexity. my current thinking for how to handle this without adding large dependencies (e.g. jsonld) to the page load is to do the translation in the API so the UI can receive exactly what it expects without any special parsers. that isn't to say we won't support JSON-LD / RDF, we'll just have an API service layer that handles parsing, translation, caching, etc so the UI code doesn't have to. i'm still letting this simmer though.

[bhaugen]

@fosterlynn @elf-pavlik @ahdinosaur can we take some of the discussion above into an issue in the main valueflows repo?

[elf-pavlik]

an id is a URL, so that's enough to handle data distributed across domains, assuming each domain provides the data in the proper format. anything more than a single state object exactly as the Holodex user interface code expects is additional complexity.

sounds relevant to Discovery of (Qualified/N-ary) Relations

Most applications don't want to get all the data, lets say from http://edgeryders.org (3000 accounts of individuals and maybe 100 groups) just to get information about one person and groups this person participates in...

For queries like label: 'People who steward {target}' I recommend checking out

• http://linkeddatafragments.org/
• http://www.hydra-cg.com/spec/latest/triple-pattern-fragments/

Or for simple traversals, my collection proposal based on ldp:DirectContainer and brainstorming in Hydra group

[ahdinosaur]

@elf-pavlik how would you generate a human readable label from a triple pattern fragment? i've had this in mind as what we'd eventually do, but for the sake of getting something working we're currently more or less hard-coding the labels for queries by each relationship type.

also getting something working is the reason why we just serve all the data instead of implementing intelligent queries or pagination, baby steps. :footprints:

[ahdinosaur]

@elf-pavlik made a dedicated issue for queries, would be great if you could direct your response to above question there.

@bhaugen i think everything here is now in dedicated issues, thanks for the push.