-----BEGIN PGP SIGNED MESSAGE-----
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
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 , 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.
<http://example.org/persons/kcoyle> a bf:person;
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;
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;
to the picture to connect a resource in the VIAF domain with its
VIAF identifier and canoncical VIAF URL.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----