Reduce the jargon

[dbooth-boston]

From https://lists.w3.org/Archives/Public/semantic-web/2019Jan/0002.html

It might be easier for
complete newbies if plainer language was used:

• Resource -> Thing
• Predicate/property -> Relation

Then a statement would be:

Thing–Relation–Thing

I understand the heritage behind the current naming, but for a newbie the
first hurdle is understanding that "resource" has a different meaning to
the one in the dictionary, that it actually means "thing". The dictionary
definitions of "predicate" and "property" also don't correspond to the
center position of an RDF triple in my opinion, whereas the dictionary
definition of "relation" does.

Consequences would be RDF becomes TDF, or simply DF, to avoid redundancy.
URI unfortunately becomes UTI, though it could be shortened in a similar
way to simply UI.

I know it likely won't be a popular idea, but if you're looking for the
perspective of relative newbies that's one about jargon I can share.

[akuckartz]

Funny, but no, please do not do that.

[anthonymoretti]

If for the moment we forget renaming RDF and URI, you don’t find that

Thing–Relation–Thing

is simpler than

Resource–Predicate–Resource ?

Very curious what people think as this was my proposal.

[chiarcos]

Please don't. It would be good to have a non-technical intro using graph terminology to introduce RDF terminology (and when we write introductions in text books, this is exactly what do) -- and we should --, but please don't touch the technical terminology (ever).
"RDF resource" sounds somewhat misleading, though, and my non-technical term (before introducing "RDF resource") is "node" -- but this is actually an incorrect oversimplification, because properties can be subjects and objects of RDF statements. "Thing" would have similar connotations (from OWL), and then you end up with statements like that owl:Nothing is a Thing. So there is a good reason for keeping framework-specific terminology.
IMHO, the only feasible work-around to avoid confusion with, say (language) resource or (grammatical) subject, etc., is to systematically use the terms "RDF resource" and "RDF subject".

[anthonymoretti]

Because of punning anything can be considered an owl:Thing though, right? So because owl:Nothing is an owl:Class, and classes can be things due to punning, can't owl:Nothing also be an owl:Thing?

I'm no expert by any means, but I always thought owl:Thing was equivalent to rdfs:Resource. So any illogical sounding statements involving "Thing" would already have equivalent illogical sounding statements involving "Resource" it seems.

[draggett]

The terminology will also depend on the level of the representation - if we're directly supporting n-ary relationships, something I think we should, then we may want to consider using terms relating to objects, properties and relationships. This would also lead to easier to learn serializations for data and rules. My understanding is that to reach the middle 33% of developers, we need something different from the existing RDF framework, albeit something formally built on top of that.

[draggett]

I note that the Property Graph folks don't seem to have an agreed term for graph nodes with properties, although some have considered "entity". In Cognitive Psychology, the agreed term is "chunk". Minsky used the term "frame". I reckon that "object" or "thing" are good candidates.

[anthonymoretti]

Do you mind expanding the point about the effect n-ary relationships might have on the terms?

I also find "object" familiar, but probably because of my experience with OO I think. "Entity" and "chunk" seem like jargon, whereas "thing" is used in everyday speech - something, nothing, anything, everything. Even taking a look at https://www.w3.org/TR/rdf11-concepts/#resources-and-statements, that section of text refers to things and relations.

[draggett]

Do you mind expanding the point about the effect n-ary relationships might have on the terms?

At the RDF core, we only have triples with subject, predicate and object. In many cases, people think at higher level, e.g. things with properties, and relationships between things, it it is an unnecessary burden to have to mentally map this into RDF triples.

Some further observations: In principle, relationships between things can also be seen as thing valued properties of other things. Metadata on the relationship can then be considered as sub-properties. However, I think that people like to distinguish relationships and properties, so it is helpful to have a way to do so. A relationship with metadata annotations can be modelled as a thing with the annotations as properties. I am interested in how to support these distinctions without confusing newcomers.

A further observation is the connection to the Web of Things, where things are digital twins for sensors and actuators, and exposed to applications as software objects with properties, actions and events. Things have RDF identifiers as a basis for describing the kinds of things, their relationship to the context in which they reside, and the object model with which they are exposed to applications. It would be great to have a common terminology, e.g. things, properties and relationships, to which the web of things adds actions and events.

I think all this points towards a higher level serialization for data, models and rules, that is formally layered on top of the RDF core.

[chiarcos]

I'm no expert by any means, but I always thought owl:Thing was equivalent to rdfs:Resource. So any illogical sounding statements involving "Thing" would >already have equivalent illogical sounding statements involving "Resource" it seems.

Yes, but having the term "thing" at the level of RDF makes the *apparent* contradiction it conveys much more prominent than only having it within OWL. I barely ever used owl:Thing in data modeling (in inferences, of course), but an "RDF thing" would be rather ubiquituous. Having that said, I would not object such a term in a meta language or higher-level data model that builds on top of RDF, as long as it is properly distinguished from RDF itself.

[anthonymoretti]

So something similar, Dave, to the distinction in OWL between object properties and data properties? Using the terms I proposed you’d have this hierarchy:

Relations
    Thing relations
    Data relations

On “resources”, if “nothing is a thing” appears contradictory then “nothing is a resource” appears equally contradictory, just in my view of course.

[chiarcos]

> So something similar, Dave, to the distinction in OWL between object > properties and data properties? Using the terms I proposed you’d have > this hierarchy: Relations Thing relations Data relations On “resources”, if “nothing is a thing” appears contradictory then “nothing is a resource” appears equally contradictory, just in my view of course.

Strictly speaking, neither "nothing is a thing" nor "nothing is a resource" are contradictory, just counterintuitive. But I did not recommend to say "nothing is a resource", but "owl:Nothing is an *RDF* resource". Not because the term is particularly good, but because it's unambiguous. BTW: Of course, data is not a thing, right?

[HughGlaser]

Yeah. Touching the current formal terminology is not a good Thing, and shouldn't be necessary.
But conventions and agreements are good.
And it is not unusual to have common synonyms used for practical realisations of formal treatments.

And I do find there are problems.
Eg.:
"Resource" has no intuition (for mortals).
I would much prefer Thing (even if it is in OWL (too?)) - I don't like things like Object, because they are too concrete for me.
But I see the problem that Resource is well-embedded, so I think we live with that.

However.
What exactly should I call Relations when I talk to people?
They may even have already seen people talk about Properties, Predicates, Edges, Arcs and a bucket-load of other things, I suspect.
Anyway, aren't Properties Relations?
Oh, no, Properties describe Relations - so that's very clear than, especially when apparently if I use it as such, it is a Predicate.
Properties is wrong - it makes things look uni-directional.
Predicates needs some logic background, or it makes no sense.
Edges, Arcs, Orcs, etc. require a graph background.
Relation has a shedload of good intuition.

Can't we (please) just use Relation, and agree to do so?

I have a bunch of other trivial-seeming things like this that I think require no actual work, and I think would help, that I will get around to posting soon, I hope.

[anthonymoretti]

“Data is not a thing, right?” I don’t really know if this is an answer, but rdfs:Literal is a subclass of rdfs:Resource, so maybe the answer is yes?

I agree with Hugh’s points about relations, the term is self explanatory.

Is it really too much though to add rdfs:Thing, and maybe very slowly, e.g. 5-10 years, deprecate rdfs:Resource? We have a description framework and the most central concept is poorly described. After working with RDF for a long time of course you get used to it, but the discussion is about getting adoption, and “Resource” is immediate and pervasive jargon for newcomers.

[chiarcos]

“Data is not a thing, right?” (...) maybe the answer is yes?

I think so, too. But formulating an opposition between "Data relations" and "Thing relations" implies that it is not.