Talk:Common Naming Project

Not sure where this goes on the main page, but it is from my email and it seems relevant:

(The document at has this as one of its statements)

<> commonsNaming:hasSharedName <> . <> commonsNaming:fromDatabase <> . <> dc:identifier "pubmed:15456405" . <> rdf:type <> .

Note that the rdf:type which is given by a particular provider should be specific to that provider, as it can be used to infer supported properties.

(The document retrieved using has this in its HTML head element)

<link rel="alternate" type="application/rdf+xml" title="CommonsSharedName" href="" />

(The document retrieved using has)

<> rdf:type <> . <> dc:identifier "15456405" . <> commons:hasRdf <> . <> commons:hasHtml <> . <> commons:fromDatabase <> .

(The document retrieved using has)

<> rdf:type <> . <> dc:identifier "pubmed" . <> commons:hasRecordPrefix "" . <> commons:hasRdfPrefix "" . <> commons:hasHtmlPrefix "" .

Note the use of strings for the prefixes/dc:identifiers, as they are not real URI's anyway, they are just strings that people can use to make URI's, and RDF agents should never even have the desire to attempt to resolve them.

Given the structure above users have enough information to systematically construct new URI's without any human intelligence past the selection of which database and identifier to use.

The background administration for a system like that consists of people maintaining the commons:has*Prefix definitions, and doesn't need a complicated system like for delegation, as a simple web app could be made up with logins to change information in the SPARQL database(s) whose sole purpose(s) is/are to provide these definitions.