Print

Print


Jeff Young's email came through garbled.  We're not sure why and the plan is to test a few things, but I forward a clean version below.

Yours,
Kevin


> -----Original Message-----
> From: Young,Jeff (OR)
> Sent: Friday, July 11, 2014 2:03 PM
> To: [log in to unmask]
> Subject: RE: [BIBFRAME] BibFrame and Linked Data: Identifiers
>
> Richard wrote up the
> https://www.w3.org/community/schemabibex/wiki/Identifier, but I don't
> remember much discussion of it.
>
> The abandoned "info" URI effort leaves me skeptical that non-HTTP URIs can
> be systematically described in general. I'm also skeptical that individual
> identifiers of any kind need to be described inline with instance data.
>
> http://info-uri.info/
>
> Jeff
>
> > -----Original Message-----
> > From: Bibliographic Framework Transition Initiative Forum
> > [mailto:[log in to unmask]] On Behalf Of Ford, Kevin
> > Sent: Friday, July 11, 2014 1:19 PM
> > To: [log in to unmask]
> > Subject: Re: [BIBFRAME] BibFrame and Linked Data: Identifiers
> >
> > Hola Rob,
> >
> > Let me begin by commenting on this:
> >
> > > And apologies for the lack of clarity that required the re-re-
> > reading!
> > -- No apologies needed.  It’s a complex subject and my re-reading was
> > an effort to understand every nuance.
> >
> > Now, something you wrote in this most recent response made me realize
> > that perhaps there are two views of the "identifier" property that
> > require some form of reconciliation or clarification.
> >
> > It was this line:
> >
> > > If bf:uri did not assert some degree of equivalence, then it
> > shouldn't
> > > be a subproperty of bf:identifier,
> >
> > This would suggest that you believe "bf:identifier" to assert some
> > degree of equivalence.  I'm not sure that is how "bf:identifier" has
> > been viewed, at least by us.  And I just said "us" (meaning NDMSO
> > staff) but maybe it's just "me" and I hope others step in to set the
> > record straight.
> >
> > Let me begin by saying that if you understand bf:identifier as
> > essentially meaning "equivalentResource" or "owl:sameAs" or something
> > along those lines, then I totally understand your fear of someone
> > using the same URI for the bf:Identifer /and/ the bf:Instance. I'd not
> > picked up on that earlier, and it might explain why I remain somewhat
> > mystified as to why someone would use the same URI for the
> > bf:Identifer /and/ the bf:Instance and why /you/ believe it to be
> > inevitable. (Let me also say that if I am wrong about that assumption,
> > then take the remaining content of this email with a grain of salt.)
> >
> > But I don’t think /we've/ imbued the bf:identifier property with those
> > semantics, at least not intentionally.  And, for the record, nothing
> > here is meant to suggest "we're right and you're wrong" (or vice-
> > versa); I'm hoping we've hit on the point of disagreement or
> > miscommunication and, if so, figure out where to go from here.
> >
> > We've thought of the bf:identifier->bf:Identifier construct more as a
> > way to record and capture details about an "identifier" itself more
> > than a relationship that equates two like things.  Our assumption
> > presented another way: bf:Identifier represents an identifier, not the
> > Thing the identifier identifies.  (And that is why I've had a hard
> > time seeing the potential identifier collision - to me they represent
> > two distinct things.)
> >
> > At this point, I'm inclined to simply ask for comment on the above,
> > but allow me to suggest how this issue might be resolved (on the
> > assumption the above accurately captures the
> misunderstanding/miscommunication).
> >
> > Clearly the definitions of bf:identifier and bf:Identifier need to be
> > reviewed and, if necessary, modified to reflect the actual intent.
> > Bf:uri (and a whole bunch of other identifiers, such as those that can
> > be used with URIs) need to move out from being sub-properties of
> > bf:identifier so that they can be imbued with some kind of equivalency
> > semantics.  If this sounds like a reasonable first step, then I simply
> > see this as just one of the reasons identifiers in BIbframe need some
> > TLC.
> >
> > I do want to conclude by drawing attention to the real use case where
> > there are identifiers about which more information must, should, or
> > could be captured.  These data points might include who
> > assigned/created the identifier, the date of its creation, whether it
> > has been cancelled, etc.  This use case (real for BIbframe, and
> > already in good evidence in MARC) can also be seen here [1].
> >
> > Yours,
> > Kevin
> >
> >
> > [1] http://www.w3.org/community/schemabibex/wiki/Identifier
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Ford, Kevin
> > > Sent: Friday, July 11, 2014 12:00 PM
> > > To: Ford, Kevin
> > > Subject: RE: [BIBFRAME] BibFrame and Linked Data: Identifiers
> > >
> > >
> > >
> > > From: Bibliographic Framework Transition Initiative Forum
> > > [mailto:[log in to unmask]] On Behalf Of Robert Sanderson
> > > Sent: Thursday, July 10, 2014 5:29 PM
> > > To: [log in to unmask]
> > > Subject: Re: [BIBFRAME] BibFrame and Linked Data: Identifiers
> > >
> > >
> > > Hi Kevin,
> > >
> > > On Thu, Jul 10, 2014 at 1:43 PM, Ford, Kevin <[log in to unmask]> wrote:
> > > > An example in the documentation of when this isn't the case is in
> > > > bf:uri (  http://bibframe.org/vocab/uri.html ) where there is a
> > real
> > > > resource as the object of the bf:uri predicate.
> > > > And thus that it could have properties like identifierQualifier,
> > > > identifierAssigner and so forth.  Maybe that's the intent, but it
> > > > doesn't really seem that way?
> > > I think this is a mistake.  So, actually, thanks for bringing that
> > > to
> > our attention.
> > >
> > > Okay, that was one of the pieces of evidence that I was basing my
> > > opinion on, so please bear that in mind!
> > >
> > >
> > > > Now consider:
> > > >   _:LotR a bf:Instance ;
> > > >       bf:uri <http://example.com/identifiers/book1> .
> > > >   <http://example.com/identifiers/book1> a bf:Identifier ;
> > > >       bf:identifierValue "some string identifier here" .
> > > > Now it becomes very odd.
> > > Oh, yes, it is extremely odd.  The more so because every time I look
> > > at that example I think to myself, "who in their right mind would do
> > > that?"  :)
> > >
> > > Heh :)  Well, yes, I hope that no one would do that, but following
> > > automated rules for the skolemization of blank nodes, systems might
> > do it unwittingly...
> > > such as the examples on the site actually do today.
> > >
> > > To pick one at random, and dropping the namespace declarations:
> > >
> > >   <bf:Identifier rdf:about="http://bibframe.org/resources/sample-
> > > bl/007177759identifier40">
> > >     <bf:identifierScheme>issn</bf:identifierScheme>
> > >     <bf:identifierValue>1471-2989</bf:identifierValue>
> > >     <bf:identifierAssigner>02</bf:identifierAssigner>
> > >   </bf:Identifier>
> > >
> > > And no, I'm not trying to say that the examples were created by
> > people
> > > not in their right mind :D Just that it's a pretty easy trap to fall
> > into.
> > >
> > >   Actually, my confusion comes a little later when the URI for the
> > > bf:Identifier is suddenly the same as that for the bf:Instance.
> > Please
> > > don't misunderstand, I comprehend your overall point, but I remain
> > > confused as to why anyone would use the URI of an Instance as the
> > > URI for a bf:Identifier.  It seems like that individual is just
> > > asking
> > for trouble.
> > >
> > > Yes. Indeed! And hence bf:uri seems like an invitation to trouble
> > that
> > > could be gainfully avoided.
> > >
> > >
> > > Anyways, in the end....
> > > > The solution (as above) is just to use bf:Identifier, always as a
> > > > blank node, for only identifiers that are not themselves URIs.
> > > I think I can sign on to this, but I'm not confident that this rule
> > > resolves this particular identifier issue as I see it.  And so
> > > begins
> > the excursion...
> > > After reading, and re-reading, and re-reading your email and
> > document,
> > >
> > > Thank you for the time! And apologies for the lack of clarity that
> > > required the re-re-reading!
> > >
> > > I can't help but think the problem is the bf:uri property itself.
> > It's
> > > a property, so it should relate two things, yet I do not believe the
> > > right semantics are being captured in this case.  I agree, if you
> > have
> > > a URI, you have a URI.  It identifies something already.  It's the
> > > "what" that I do not think is being addressed.  Is the URI an
> > identifier for the current resource?
> > >
> > > That was my interpretation, given the range of bf:Identifier.
> > >
> > >
> > > That is, is it about same-ness (some form of equivalency or
> > owl:sameAs
> > > relationship)?  Or, given a different context, the thing you have
> > > might be a URI but the appropriate relationship is something else
> > > altogether.  Of course, you'd want to use a property that captures
> > the
> > > nature of the relationship versus the rather non-descriptive bf:uri.
> >
> > > To ask all of that another way, when does one use bf:uri?
> > >
> > > Right. If bf:uri did not assert some degree of equivalence, then it
> > > shouldn't be a subproperty of bf:identifier, described as "Number or
> > > code that uniquely identifies an entity."  (sic, I guess, as the
> > > property isn't a number of code, that's the property's range, but I
> > > needlessly digress)
> > >
> > > Instead it could be a subproperty of bf:relatedTo ... but I have no
> > > idea how it would be any different to relatedTo.
> > > And so...
> > >
> > > Does this
> > >  _:LotR a bf:Instance ;
> > >      bf:uri <http://example.com/identifiers/book1> .
> > > mean this?
> > >  _:LotR a bf:Instance ;
> > >      bf:equivalentInstance <http://example.com/identifiers/book1> .
> > >
> > > I think so?
> > >
> > > (I might have made up the bf property for demonstration purposes,
> > > but you get the idea.)  If so, then would it not be better to use
> > > bf:equivalentInstance, which is far more explanatory, than bf:uri?
> >  Or
> > > is knowing the type of identifier more important?  (Really, those
> > > are not rhetorical questions.)
> > >
> > > I think that bf:equivalent, ore:similarTo, owl:sameAs or other
> > > appropriate relationship, is the way to go.
> > > And, given that the Identifier has identifierScheme, the type of
> > > identifier can be found out from there.
> > > Currently it's quite possible to say the meaningless:
> > >
> > >   _:instance bf:coden _:doi .
> > >   _:doi identifierScheme "doi" .
> > >
> > > Now what? Is it a DOI or a coden?
> > >
> > > bf:hdl (http://bibframe.org/vocab/hdl) is another one that I find
> > > similarly lacking in strong semantics.  Add bf:urn to that as well.
> > >
> > > Yup. Going though the subproperties of identifier with a fine
> > > toothed comb would be instructive, I think!
> > >
> > > This last case is interesting because a URN is a URI.  So, to be
> > > clear, would bf:urn fall under the rule your proposed above?  (Your
> > > document would suggest as much, which is all fine by the way I'm
> > > just looking for clarification.)
> > >
> > > As a URN is a URI then yes, it shouldn't be used with Identifier.
> > >
> > >
> > > Does this capture the semantics better _:LotR a bf:Instance ;
> > >     bf:doi _:bnode1
> > > _:bnode1 a bf:Identifier
> > >    bf:identifierValue "10.1000/182"
> > >    bf:identifierAssigner <http://example.org/1>
> > >
> > > than this
> > >
> > > _:LotR a bf:Instance ;
> > >     bf:identifier _:bnode1
> > > _:bnode1 a bf:Identifier
> > >    bf:identifierType <http://id.loc.gov/vocabulary/identifiers/doi>
> > >    bf:identifierValue "10.1000/182"
> > >    bf:identifierAssigner <http://example.org/1> ?
> > >
> > >
> > > I prefer the second as it associates properties of the identifier
> > with
> > > the Identifier resource, namely its DOI-ness, rather than relying on
> > > the relationship between that particular Instance and the Identifier.
> >
> > > As above, what if there's a mismatch? Or what if another Instance
> > > has a relationship to that Identifier, like cites or references?
> > > [Yes, it should cite the Work, not the Identifier, but I hope you
> > > see the point]
> > >
> > >
> > > Perhaps it makes little difference and I'm splitting hairs.
> > >
> > > No, I think it does make a big difference.
> > >
> > >
> > > That said, one of the points you raised in the document was how, for
> > > example, an ISSN has a formal URN form and therefore could be
> > > represented as a URI (did not know that, so thanks).  Taking
> > advantage
> > > of such a mechanism, I could see a scenario where the property
> > bf:issn
> > > is defined as something like "ISSN for current resource in URN form"
> > > and reserved solely to allow something like this:
> > >
> > > _:I1 a bf:Instance ;
> > >     bf:issn <urn:ISSN:1560-1560> .
> > >
> > > Yup, +1.  And bf:issn then isn't a subproperty of bf:identifier.
> > > Otherwise it could be simplified to:
> > >
> > >     <urn:ISSN:1560-1560> a bf:Instance .
> > >
> > > modulo the trust issue discussed in the Authorities thread.
> > >
> > > while still allowing this:
> > >
> > > _:I1 a bf:Instance ;
> > >     bf:identifier _:bnode1
> > >
> > > _:bnode1 a bf:Identifier
> > >    bf:identifierType <http://id.loc.gov/vocabulary/identifiers/issn>
> > >    bf:identifierValue "1560-1560"
> > >    bf:identifierAssigner <http://example.org/issn/agency>
> > >
> > > Agreed.  I see the point of Identifier for non URIs (including URN
> > and
> > > URL as subsets of URI)
> > >
> > >
> > > The immediately preceding two examples would establish a model
> > whereby
> > > "bf:identifier" and "bf:Identifier" are used when capturing
> > > information about other, string-based identifiers while reserving
> > > the properties (bf:issn, bf:isbn10, etc) exclusively for URI-ified
> > > identifiers.  This aligns, I believe, more or less with your rule;
> > I'm
> > > wondering if there is a way to refine when select properties are
> > > used and when they are not (providing there is merit to that idea).
> > > I'm also looking at how they are defined.  Does that make sense?  Do
> > > you
> > foresee issues with or benefits of allowing for this type of
> > duplication?
> > >
> > > Nope, other than the semantics of bf:issn in terms of the
> > relationship
> > > between the subject and object.  If it's owl:sameAs, then the ISSN
> > > could be (again modulo the trust issue) the identifier for the
> > > Instance directly, rather than using a blank node and saying it's
> > > the
> > same as a URI.
> > >
> > > OK, I feel I rambled on a bit; I hope it was clear.
> > >
> > > It is, thank you!
> > >
> > > All of it is to basically say that I think you raise a good point,
> > but
> > > that I am trying to flesh it out some.  Thanks for taking the time
> > > to
> > write it all down.
> > >
> > > And for you to read and reply in such a considered fashion :)
> > >
> > > Rob