Add semantics to NetworkLink and networkConnection

[rjyounes]

Domain and range of networkConnection should be NetworkNode. This entails, correctly, that a resource is a NetworkNode by virtue of being at one end of a networkConnection.

NetworkLink should be required to have a networkConnection to exactly two resources.

[uscholdm]

That sounds correct - so long as we cannot conceive of having a networkConnection to/from something that is not a 'full fledged' network node (whatever that might mean).

Also the name of the property should probably be something like networkConnectedTo, and perhaps a subproperty of gist:connectedTo?

[rjyounes]

Should start with a verb as per proposed conventions, so isNetworkConnectedTo or similar. Yes, subproperty of connectedTo makes sense.

[uscholdm]

Its not always black and white:
WHITE: performs: is a verb, plain and simple, no need to add anything to verbize it.
BLACK: partOf is not a verb nor is part (were not talking about hair here), part is a noun. So is best to use the verb form: isPartOf
GRAY: connectedTo: connect is in fact a verb, so adding "is" is not really needed.
Depending on what your preference for is is, we can do with or without it. My preference is to leave verby property names as they are, and refrain from 'izzing' them.

[rjyounes]

I agree with your WHITE and BLACK cases, and this is what I've written up in my conventions proposal.

However, I disagree on the GRAY case: in the past I have waffled between isConnectedTo and connectedTo, but on further analysis the "is" form is correct if we follow the verb-initial convention. The suffix "ed" is deceptive, because it is used to form adjectives as well as past tense verbs and past and passive participles. (The fact that the adjectival forms most likely derive historically from passive participles is irrelevant here, I think.) The "ed" forms used in RDF predicates are generally adjectives rather than verbs. Certainly these are not to be interpreted as past tense verbs, and they generally are not passive participles either. E.g., "married" in a hypothetical predicate "marriedTo" is an adjective rather than a passive participle. "Connected" in "connectedTo" is similarly an adjective; we do not mean Tom is/was connected to Mary BY SOMEONE, we mean Tom IS CONNECTED to Mary - an adjective.

In any case, "network" is not a verb, thus I propose prefixing "is" or possibly rewording in some other, more idiomatic way, such as "isConnectedToInNetwork" (unfortunately, awkward even though more idiomatic).

[uscholdm]

n any case, "network" is not a verb
It's an adverb that indicates a particular kind of connectedTo. Overall it adds up to a verb phrase. But this is into quibble territory, I fear :-).

I agree that adding 'is' reads better. Another argument for it is to not have to stress over the GRAY areas. Just use is and get on with it. And it only takes up a teeny amount of extra scene real estate.

[rjyounes]

Also networkConnection should be Symmetric.

[uscholdm]

It should be a verb, also. Perhaps networkConnectedTo. Or maybe just connectedTo which could also be used to connect things that are not network nodes.

[rjyounes]

Review meeting: we need to get input from Dave about what the intent of NetworkLink is. Assigning to Michael to follow up with Dave.

[rjyounes]

PROPOSAL:

• Range of networkConnection and subproperties is NetworkNode
• Domain of networkConnection and subproperties is NetworkLink
• Rename networkConnection to be verbal - name TBD

This allows things connected in a network (e.g., people in a social network) to be inferred to be NetworkNodes rather than having to assert that (it's odd to assert that a person, e.g., is a NetworkNode).

Delayed till next major release.

[rjyounes]

Michael: verify with Dave.

[rjyounes]

TBD: new name for networkConnection.

[uscholdm]

TBD: new name for networkConnection

We want the meaning relationships to be reflected in the languaging of the terms. Suggestions:

• hasNode, hasFromNode and hasToNode (less disruption)
• connects, connectsTo, connectsFrom (much more like English)

NetworkLink refies an arbitrary connection between two things, which are nodes in the network. Say Rebecca and Dave are non-directionally connected in a social network. We might have this:

:_NetworkLink:_RY_and_DMc :connects :_Person_DMc , :_Person_RY ;
                          :memberOf :_Network_MySocialNetworkConnections .

Suppose Rebecca and I are in social likes network. I like her but there is no evidence that she likes me.

:_NetworkLink:_RY_and_MFU :connectsFrom :_Person_MFU ;
                          :connectsTo :_Person_RY ;
                          :memberOf :_Network_MySocialNetworkLikes .

[rjyounes]

@uscholdm An issue with your instance URIs: we don't have a class gist:Network. Is that a requirement for using the infix convention? Maybe not - otherwise you'd have the unhelpful :_Thing_MySocialNetworkLikes or maybe just :_MySocialNetworkLikes.

However, adding a gist:Network class is a good idea, IMO.

[rjyounes]

@uscholdm I wouldn't worry about disruption since these are major changes anyway. I like using "connects," but I would prefer more specific predicate names to indicate these apply to the network context only. And we already have connectedTo, which will certainly cause confusion.

How about: connectsNetworkNode, connectsToNetworkNode, connectsFromNetworkNode?

[uscholdm]

Gist 9.5 has gist:Network, which version are you looking at?

[uscholdm]

How about: connectsNetworkNode, connectsToNetworkNode, connectsFromNetworkNode?

First thought: Does not read well, is over-long and unnecessary. The range is NetworkNode.
Second thought: Yes there is confusion with gist:connectedTo which is serving a different but closely related purpose. Need to mull this over a bit more.

[rjyounes]

I missed gist:Network since I didn't think to look under gist:Artifact. As a separate issue, maybe it should be a subclass of gist:System. If you think that's worth considering, I'll add a new issue.

Since we have gist:Network, should we also add restrictions to NetworkNode and NetworkLink to the effect that they are gist:memberOf a Network?

Wrt naming, how about changing connectedTo to relatesTo, and using the connects names for the network. relatesTo is very vague, but so is connectedTo. Since this is already a major change, piling on more major changes won't hurt.

[uscholdm]

The more I think about this, we might be just representing a pure mathematical graph which is nothgin more than a set of nodes and arcs with direction being optional. So it would not be a subclass of gist:System which is "an artifact with component parts where the parts contribute to the goal of the system" Need to ponder this a bit more.

[rjyounes]

DECISION:

• Rename properties to links (superproperty), linksTo, linksFrom (subproperties).
• Deprecate existing properties.
• Properties have no domain and range
• Restriction on NetworkLink that it has to have 2 links relationships, with filter class NetworkNode
• Add additional restrictions on NetworkLink and NetworkNode that they must be memberOf Network.