Interpretation of a resource of type skos:Concept

The question is, if I state:

@prefix skos: <http://www.w3.org/2004/02/skos/core#>.

<http://www.example.com/aURI>  a  skos:Concept.

... what does that statement mean? I.e. what does it imply about the thing that the URI http://www.example.com/aURI denotes?

One option for the skos:Concept class is to say that, when involved in a statement such as the above, it implies that the given URI denotes an abstract concept. But abstract concepts only exist in a person's head, as patterns in the mind (or something like that). So does this URI denote a concept in my head only? Is everybody who uses this URI now referring to an idea in my head, or an idea in their own heads? How do I know their idea is the same as mine?

I think the most practical solution is to say that yes, strictly speaking this URI denotes an idea in my head, and you should come mind meld with me if you want to know what I'm thinking about. But functionally it serves as the focus for a description of that concept. So for example I could additionally state that:

@prefix skos: <http://www.w3.org/2004/02/skos/core#>.

<http://www.example.com/aURI>  a  skos:Concept;
  skos:prefLabel  'bananas';
  skos:definition  'a long curved fruit with a yellow skin and soft, sweet white flesh inside.';
  skos:scopeNote  'Does not include plantains.';

( ... and btw this set of RDF statements is then a description of the concept in my head.)

I could equally publish a prosaic (rather than RDF) description of this concept, e.g.

The URI <http://www.example.com/aURI> denotes the concept of a banana, which is defined as a long curved fruit with a yellow skin and soft, sweet white flesh inside. This concept does not include plantains.

If I publish a good description of this concept (in RDF, prose, or anyhow), and everybody who uses the concept reads this description, then there is a high likelihood that other people will come to use this URI in the same way that I do. If it's a poor description, other people may come to a different interpretation, and so the URI will be used inconsistently.

What this boils down to is language. I have invented a new 'word'. The nice thing about using URIs as words is that some person (or organisation) definitely owns that word. It is up to the word owner to make sure that everybody else knows what that word is supposed to mean, and how it should be used, if the word is to become useful.

And like normal words, URIs should be opaque ... i.e. you shouldn't assume anything about what the word means just by looking at it.

Actually most words are *not* opaque. They are constructed from roots, prefixes and suffixes, or otherwise derived from other words, in the same or other languages. One can guess the meaning of "anticonstitutionnellement". (Bernard Vatant)

But what does this argument mean in practise for HTTP URIs? Should we call on whoever owns the HTTP URI scheme to state explicitly the range of things that HTTP URIs can be used to refer to, and then make sure we are all good citizens? Or, because the HTTP URI scheme delegates ownership of a set of URIs via the DNS system, does that mean that they also delegate (and hence abdicate from) the responsibility for establishing (or restricting) meaning? Or in other words, if I 'own' a set of HTTP URIs, is it OK for me to do what I like with them?

It has been argued that HTTP URIs without hashes (slash URIs) should only be used to denote (i.e. refer to) some kind of information resource (i.e. a 'document'), because of the risk of confusion through URI collision. But most people have managed to use the dublin core element set version 1.1 in a fairly consistent manner (or have they?). Nobody thinks the URI http://purl.org/dc/elements/1.1/title denotes a document (or do they?). The same goes for FOAF. On the other hand, there has been some confusion about what the URI http://purl.org/dc/elements/1.1 denotes.

So if we were to say: do what you like with your HTTP URIs, just make damn sure everybody else knows what you expect them to do with them ... would that be OK?