To look at google 'Things, not strings' from 2012 from a different perspective:
Why, in many ontologies, such as gist, elements such as addresses or address components are not represented as strings, but as objects.
This forces us to attach strings to these objects. How impractical. One more hop to get to the printable address.
I have often been asked this, and I well remember that this also irritated me when I first got involved with RDF.
What I mean is that instead of
@prefix ex: <http://example.org/exampleOnt/> .
ex:_HubertMayer ex:hasAddress "Mayerstr. 1, 99999 Mayerstedt" . something like
@prefix ex: <http://example.org/exampleOnt/> .
ex:_HubertMayer ex:hasAdress ex:_HuberMayersAdressse .
ex:_HuberMayersAddress ex:uniqueString "Mayerstr. 1, 99999 Mayerstedt" ..
Many examples show the first, simpler version, both in books about the Semantic Web and on websites. It is easier to understand - especially for newcomers, and it allows authors to draw the reader's attention to another point that is to be demonstrated at that point.
In practice, however, this is often a less good way of modeling data in RDF.
Because strings are not things in RDF, i.e. I cannot make any further statements about data, i.e. strings, numbers, dates. In RDF we can only make statements about "things", and for RDF these are IRIs, not data.
So if we want to say that this address is Mr. Mayer's home address, then we cannot express this in the simple form. In this case, we have to model the address as a separate object with its own IRI:
@prefix ex: <http://example.org/exampleOnt/> .
ex:_HubertMayer ex:hasAdress ex:_HuberMayersAdressse .
ex:_HuberMayersAddress ex:uniqueString "Mayerstr. 1, 99999 Mayerstedt" .
ex:_HubertMayersAddress ex:addressType ex:privateAddress ;
ex:validFrom "1999-01-01T09:00:00+01:00"^^xsd:dateTime .Here I have also added the date from which this address is a valid address for Mr. Mayer - this can also be useful.
My naive assignment of ex:_HubertMayersAddress in this example is again due to the example character of this text. In an operational application, such a name would be generated automatically, and how it is sensibly designed can be a separate topic. A simple UUID or ULID can be assigned here, or a meaningful IRI can actually be generated, although in my opinion this is not worth the effort.
By the way: the classification ex:privateAddress is again a topic of its own. Such an expression should be part of a separate taxonomy, outside the ontology. Taxonomies are often changed more quickly than ontologies, are managed by other people and should therefore be thought of separately.
There is a good video on this by Dave McComb: "How Gist marries Ontologies & Taxonomies". Worth seeing.