Consider this:
SELECT ?name
WHERE { ?s :contains :MRN; ?s a :Patient; rdfs:label ?name}
--VERSE--
SELECT ?name
WHERE {
?s ?p ?o; rdfs:label ?name.
?p rdfs:label "contains".
?o rdfs:label "Master Record Number".
?s a ?type.
?type rdfs:label "Patient".
}
Except the above would introduce the possibility of querying from the wrong
graph (when importing multiple graphs), not be supported by autocomplete/lookup
features, and result in a huge query performance degradation. This also
assumes you know the correct punctuation, spelling, etc. Otherwise you can use
a FILTER expression and REGEX, but that is even slower and requires even more
typing.
OR
PREFIX mrn: <http://www.mdanderson.org/clinical#fge29430s>
PREFIX contains: <http://www.mdanderson.org/clinical#fdk30929a>
PREFIX patient: <http://www.mdanderson.org/clinical#jkl23902c>
SELECT ?label
WHERE { ?s contains: mrn:; a patient:; rdfs:label ?name}
This final method is being proposed. Obviously, you can see this just hides
the problem and makes it even more difficult to maintain. Now the semantic
references are even more difficult to maintain, because they are stored as
plain text in a file or sparql query. You cannot query for them or consult
metadata about them. It introduces more typing and doesn't provide any real
improvement over the first case (using semantic identifiers) because you are
using semantic identifiers but instead of being URIs they are now SPARQL
Prefixes!
Someone might come along still and use MRN to mean Magnetic Resonance
Neuroimaging instead of Master Record Number, but at least they can easily find
MRN in the model by doing a simple sparql query:
SELECT ?p ?o
WHERE {:MRN ?p ?o}
Or they can quickly jump to that concept by referring to the URI. In TopBraid
Composer there is a text box where you can put a URI in and it will
automatically jump to that resource.
