Identifiers

(cross-posting a bit to the LLD XG to benefit from the insight of
people there that may not be subscribed to open-bibliography@)

* [2010-11-22 13:49:46 +0100] Makx Dekkers <mail@makxdekkers.com> écrit:

] I am not sure what you mean by "confusing in that it was a literal that
] was constructed like a URI".

This is not a question of right or wrong, but a question of best
practices. 

] In the sample I see:
] 
]     <dcterms:identifier>GBA164362</dcterms:identifier>
]
] and
] 
]     <dcterms:identifier>URN:ISBN:1850877019</dcterms:identifier>
] 
] Both are correct usage of dcterms:identifier (apart from the uppercase
] as you pointed out). In both cases the identifier is the (literal)
] string of characters. The second identifier is not just "constructed
] like a URI", it is a URI! 

Both are correct in that they conform to the range of
dcterms:identifier. The problem of the first is that it isn't obvious
what kind of identifier it is -- as it turns out it is the British
National Bibliography identifier (I think).

The second is not a URI, it's a literal. It won't be indexed in stores
as a URI, the sparql isURI and isLITERAL tests will treat it as a
literal, etc.

The reason to have urn:isbn: is so that it is at least possible to tell
what kind of a number that is, probably better to use a dedicated
predicate like bibo:isbn in which you don't need to fudge it with a
urn:isbn: prefix. 

] Yes, it may be confusing that you can use the URI in two ways: either as
] the (literal) string itself like here in dcterms:identifier, or as a
] pointer to a resource which you would do if you used it in
] dcterms:relation, for example.
] 
] Both
] 
]     <dcterms:identifier>someURI</dcterms:identifier>
] 
] and
] 
]     <dcterms:relation rdf:resource="someURI" />
] 
] are correct -- the URI just plays different roles.

Correct in terms of "are valid RDF" and "conform to the defined
semantics" but apart from some obscure cases involving reification, I
think it is not a good idea to have literals that look like URIs
without very good reason.

Cheers,
-w
-- 
William Waites
http://eris.okfn.org/ww/foaf#i
9C7E F636 52F6 1004 E40A  E565 98E3 BBF3 8320 7664

Received on Monday, 22 November 2010 13:40:00 UTC