-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 17.07.2014 16:00, schrieb Karen Coyle: > On 7/17/14, 3:43 AM, Thomas Berger wrote: >> Sure. But Rob's (absolutely valid) point are the inconsistencies arising >> from resource URIs we want to distinguish as "identifiers" simultaneously >> used as resource URI for the bf:Identifier as such. Making statements about >> some URIs (as URIs as in contrast to the resources they represent) would >> constitute a more subtle form of the same(?) fallacy and is likewise absolutely >> not admissible. >> My point of view however would be to simply dispense n URIs into m bf:Identifier >> containers and keep them striclty in object position there... > > Which *you* can do, but you cannot prevent anyone else from using them "in the > subject position." Therefore, in the open web, you cannot enforce this consistency. > > I note that all of your examples use URN forms, not http URIs, which are the LOD > standard. That could mean that we are not talking about the same thing. URNs are > by definition URIs, but in the semantic web context only http URIs are used for > subjects and predicates (although, beyond the "use http URIs" statement by TBL, > I don't see an absolute restriction in the RDF documentation). This was because I was sticking to the ISBN case. Another example (although in the realm of bf:Authorities) would be VIAF URLs where the "Peralink" is a canonical URL sanctioned by viaf.org http://viaf.org/viaf/195531823 Like ISBN URIs it is derived from the identifier as string and, since VIAF proposes use and display of the URL form to achieve ODC conformance I'm strongly inclined to regard the URL form as an identifier representation in its on right, comparable to the difference between ISBN-10 and ISBN-13. Since VIAF has started to cover (RDA) work and expression records in principle we can start crafting examples for "classical" Bibframe resources with VIAF use, at least for bf:works > What I believe you are proposing is the same that I proposed in the schema.org > variant [1], which is to have an "identifier" property for those identifiers > that CANNOT be used as subjects in RDF statements. If that is the case, then it > is essential that no URIs are used as objects of that predicate. "identifier" has unfortunately turned into a highly ambiguous term in this discussion. What we are discussing here are "more modern" identifiers crafted for web situations. In a sense we consider them the better kind of identifiers but it turns out that we have difficulties to preserve the aspects of more traditional identifiers they bear. A noteworthy example should be URN:NBN identifiers for digitized resources: Their purpose is very classic (providing national bibliographic identification) but no one even tries to regard them as composites of "identifier proper" with some silly prefix. Treating all identifier values as strings (including those which look like URIs) is one viable option and one can state This resource might commonly be identified by "http://viaf.org/viaf/195531823" Allowing URIs as identifier values (in a differently named property) seems to correspond with the "identifies" property proposed in < http://www.w3.org/community/schemabibex/wiki/Identifier >: At a first glance I found it silly that a thing has an identifier which in turn identifies a (i.e. this?) thing. But if insulate the graph for the identifier and read "identifies" as "is commonly used for" then it is exactly the property I was reasoning about. Now consider <http://example.org/persons/kcoyle> a bf:person; bf:identifier [ bf:schema "VIAF"; bf:identifierValue "195531823"; bf:identifierValueURI <http://viaf.org/viaf/195531823> ]. This states identity of <http://example.org/persons/kcoyle> with any resource carrying matching identifieres, e.g. <http://example.com/p/kc> a bf:person; bf:identifier [ bf:schema "VIAF"; bf:identifierValueURI <http://viaf.org/viaf/195531823> ]. However identity with the resource <http://viaf.org/viaf/195531823> is NOT built into that construction, it's rather "all resources relating the same way with <http://viaf.org/viaf/195531823> are pairwise equivalent" and someone would /explicitly/ have to add <http://viaf.org/viaf/195531823> a bf:person; bf:identifier [ bf:schema "VIAF"; bf:identifierValueURI <http://viaf.org/viaf/195531823>; bf:identifierValueURI <http://viaf.org/195531823>; bf:identifierValueURI <http://viaf.org/viaf/sourceID/LC|n89613425>; ]. to the picture to connect a resource in the VIAF domain with its VIAF identifier and canoncical VIAF URL. viele Gruesse Thomas Berger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iJwEAQECAAYFAlPH8kMACgkQYhMlmJ6W47N2ogQApGvTM87HR/TF9XfNoUVnRUmO Ef4/USiVPDLnhS5dgTAp3hsBAnAZ7BWHlW/EBYk6KTsJlXu+I39lWE8atf86sbki 5nYGQd3XZq5IB/BBxCbOnXLP/sHHiuRXopPeBvM3DA15GgeKaWxu9hG3lFeoKLHJ 57orOoS27Bzylx3nups= =D3yR -----END PGP SIGNATURE-----