Print

Print


It is a bit hard to explain how an abstract manifestation can have an 
extent. And where would you put extent when describing a unique item? 
Obviously on the item. Extent on manifestation is a convenience for 
describing all of the instances of a publication or production run. 
"Manifestation" could be "product description", and would not be 
included for unique items.

I believe that FRBRoo makes this distinction better, but it is also much 
more complex.

kc


On 11/18/15 7:53 AM, Steven Folsom wrote:
> I've always interpreted the Manifestation to be the abstract "version" 
> of the Work/Expression where we record traits related to that version, 
> e.g. eBook Manifestation has an extent of 325MB, or the print 
> Manifestation has 423 pages. The Item is the physical embodiment of 
> Manifestation that can be found somewhere.
>
> For example, Amazon offers different Manifestations of a 
> Work/Expression, but it’s Items located in their warehouse that the 
> will ship to you. The same goes for Libraries, we have holdings of 
> Manifestions, but it’s the Items that have locations and circulate.
>
>
> From: Bibliographic Framework Transition Initiative Forum 
> <[log in to unmask] <mailto:[log in to unmask]>> on 
> behalf of "Young,Jeff (OR)" <[log in to unmask] <mailto:[log in to unmask]>>
> Reply-To: Bibliographic Framework Transition Initiative Forum 
> <[log in to unmask] <mailto:[log in to unmask]>>
> Date: Wednesday, November 18, 2015 at 10:28 AM
> To: "[log in to unmask] <mailto:[log in to unmask]>" 
> <[log in to unmask] <mailto:[log in to unmask]>>
> Subject: Re: [BIBFRAME] Properties of Item proposal
>
>     Bruce,
>
>     I said something about solidity and **items** earlier. Is that
>     what you’re remembering?
>
>     (To be clear, I didn’t say that items had to be solid, but some
>     people have heard it that way.)
>
>     Jeff
>
>     *From:*Bibliographic Framework Transition Initiative Forum
>     [mailto:[log in to unmask]] *On Behalf Of *Gordon, Bruce J.
>     *Sent:* Wednesday, November 18, 2015 10:19 AM
>     *To:* [log in to unmask] <mailto:[log in to unmask]>
>     *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
>     Hold on. We were just told that manifestations were solid things.
>     Which is it?
>
>     -Bruce
>
>     Bruce J. Gordon
>
>     Audio Engineer
>
>     Audio Preservation Services - a shared service of the Harvard Library
>
>     Harvard University
>
>     Cambridge, Massachusetts 02138
>
>     U.S.A
>
>     tel. +1(617) 495-1241
>
>     fax +1(617) 496-4636
>
>         On Nov 18, 2015, at 10:01 AM, Steven Folsom <[log in to unmask]
>         <mailto:[log in to unmask]>> wrote:
>
>         Gordon,
>
>         I don’t think Karen is suggesting to derive
>         meaning strictly from the name or labels of the property. She
>         said the meaning comes from the semantics.
>
>         In my limited experience, as humans we come to understand the
>         semantics through axioms and annotations in the ontology,
>         and… honestly when the axioms and annotations are not not
>         enough we have to go to the property or class names,
>         documentation and examples to try to understand "the meaning".
>         [As an aside, there are ontology matching tools that recognize
>         this, and (along with other techniques) they analyze
>         the lexicalization of the names as part of their algorithms to
>         align classes and properties between ontologies.]
>
>         The criticism with <rdam:P30154> is that the semantics of the
>         property (come to be understood through the lexical aliases
>         and skos:description) are for a relationship AND what*seems to
>         be the expected range*, e.g. Has remote access + range of
>         URL. The skos:definition "Relates a manifestation to the
>         address of a remote access resource.” and the fact that the
>         range is actually undefined seems suggest something different
>         from the lexical aliases. One could get remote access to a
>         resource through a phone call, so is a telephone number a
>         valid object of the <rdam:P30154> property?
>
>         I know Karen is advocating below for a more
>         general rdax:location property, but maybe in this case we
>         would want a more general rdax:access relationship that
>         represents access to the resource. The object (in this
>         scenario, a point of access) can be described through
>         additional assertions about the point of access, whether it be
>         a website, library, etc. The website and libraries can have a
>         locations.
>
>         I’m not a RDA/FRBR expert, so I wondering what it means for a
>         Manifestation to have a location at all. My sense is that
>         Manifestations are still conceptual entities, and it would be
>         Items that have locations.
>
>         respectfully,
>
>         Steven
>
>         *From:*Bibliographic Framework Transition Initiative Forum
>         <[log in to unmask] <mailto:[log in to unmask]>>
>         on behalf of Gordon Dunsire <[log in to unmask]
>         <mailto:[log in to unmask]>>
>         *Reply-To:*Bibliographic Framework Transition Initiative Forum
>         <[log in to unmask] <mailto:[log in to unmask]>>
>         *Date:*Wednesday, November 18, 2015 at 6:40 AM
>         *To:*"[log in to unmask]
>         <mailto:[log in to unmask]>" <[log in to unmask]
>         <mailto:[log in to unmask]>>
>         *Subject:*Re: [BIBFRAME] Properties of Item proposal
>
>             Karen and others
>
>             <rdam:uniformResourceLocator.en> is a URI, as the
>             angle-brackets indicate.
>
>             Actually, it's an RDA lexical alias that points to the
>             canonical URI <rdam:P30154>. Lexical aliases are intended
>             to give programmers some mnemonic support by reflecting
>             the lexical label of the property in the "URI". Other
>             lexical aliases for this URI are
>             <rdam:uniformResourceLocator.de>,
>             <rdam:localizadorUniformeDeRecurso.es>, and
>             <rdam:adresseURL.fr> (awaiting activation). This
>             human-readability comes at the cost of duplicating lexical
>             aliases to preserve the mnemonic function if the property
>             label changes, or perceptual semantic drift from the
>             mismatch of alias and label.
>
>             This is a main reason why it is good practice to avoid
>             embedding human-readable strings in a URI: human language
>             changes and "meanings" drift, but URIs should be
>             consistent persistent global identifiers. A more
>             fundamental reason is that RDF works by completely
>             separating the machine-readable identifier from the
>             human-readable string. RDF expects all of the
>             human-readable data in a triple to be stored as an object
>             literal. Everything else is a URI.
>
>             The value of RDF data lies in the machine-programmable
>             semantics of ontological statements about a property or
>             class, and the human-readable definitions and scope notes
>             stored as the objects of dataset triples. Using labels to
>             store "meaning" involves too many issues; e.g.
>
>             <http://rdaregistry.info/Elements/e/P20003
>             <https://urldefense.proofpoint.com/v2/url?u=http-3A__rdaregistry.info_Elements_e_P20003&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=uQXZeWRUjobV9dpubys5KvvOk2d5rIVp0K4DPD2I0Fs&e=>>
>             reg:lexicalAlias
>             <http://rdaregistry.info/Elements/e/otherDistinguishingCharacteristicOfTheExpression.en
>             <https://urldefense.proofpoint.com/v2/url?u=http-3A__rdaregistry.info_Elements_e_otherDistinguishingCharacteristicOfTheExpression.en&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=KLKthPwPYscCA1ttgJ44bOupnCC2erRVdyX40g7aEFA&e=>>
>             .
>
>             The RDA Registry English label for the URL property P30154
>             is "has Uniform Resource Locator"@en; there is a variant
>             RDA Toolkit label "Uniform Resource Locator"@en, and an
>             internal Registry label“"uniformResourceLocator"@en. These
>             labels are currently translated into French, German, and
>             Spanish in the Registry and Toolkit.
>
>             So a machine would "see", e.g.:
>
>             <http://digital.nls.uk/78693432
>             <https://urldefense.proofpoint.com/v2/url?u=http-3A__digital.nls.uk_78693432&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=gwTdb97bOEhwgyY92A_qYXCwZnWFr-e6JJCS6hDZKuY&e=>>
>             <http://rdaregistry.info/Elements/m/P30154
>             <https://urldefense.proofpoint.com/v2/url?u=http-3A__rdaregistry.info_Elements_m_P30154&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=hVrrUTKHYsiN0qdTx5XJ53s33l7uTeHKHMxuhlKdklE&e=>>
>             "http://digital.nls.uk/rlstevenson/browse/pageturner.cfm?id=78693432
>             <https://urldefense.proofpoint.com/v2/url?u=http-3A__digital.nls.uk_rlstevenson_browse_pageturner.cfm-3Fid-3D78693432&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=ToXMkFMKfI03GSWT-upoU0WlJoNTT6n25uosbFL1Omw&e=>"
>             .
>
>             The URL string that is the object of this triple is
>             clearly not intended to be permanent, and will return a
>             404 error when the publisher of this manifestation stops
>             using a ColdFusion database server. The publisher
>             recognizes this by providing a permanent URL that can be
>             used as the canonical URI of the manifestation.
>             Furthermore, the manifestation is currently embedded in a
>             larger aggregate manifestation that can be accessed from
>             this and every other "page" URL provided by the service.
>             This URL moves the service to the first page of the
>             manifestation described, but the last page is not recorded
>             (in human or machine-readable form) so the manifestation
>             segues into the next manifestation with URI
>             <http://digital.nls.uk/78693516
>             <https://urldefense.proofpoint.com/v2/url?u=http-3A__digital.nls.uk_78693516&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=7E3bo-S145t45afqm9K7f6bGYvZbd135IpG4oVKcmmQ&e=>>.
>
>             I think it is better to leave this URL as a string in RDA
>             data. I don't think RDA is overloading or masking the type
>             of the value; isn’t that what Jeff is proposing?
>
>             The semantics of the value are made clear by the property:
>
>             <http://rdaregistry.info/Elements/m/P30154
>             <https://urldefense.proofpoint.com/v2/url?u=http-3A__rdaregistry.info_Elements_m_P30154&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=hVrrUTKHYsiN0qdTx5XJ53s33l7uTeHKHMxuhlKdklE&e=>>
>
>             a rdf:Property ;
>
>             rdfs:domain <http://rdaregistry.info/Elements/c/C10007
>             <https://urldefense.proofpoint.com/v2/url?u=http-3A__rdaregistry.info_Elements_c_C10007&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=lue5wJNbmdK6QW7LhO4mPD61UTEZEyVHhJzLtSzoWFI&e=>>
>             ;
>
>             skos:definition "Relates a manifestation to the address of
>             a remote access resource."@en
>             <mailto:%22Relates%20a%20manifestation%20to%20the%20address%20of%20a%20remote%20access%20resource.%22@en>
>             .
>
>             The RDA instructions, given in my earlier post, do not
>             burden the cataloguer with any of this. The RDA Steering
>             Committee intends to develop the instructions to make
>             explicit reference to recording URIs for RDF linked data,
>             following recommendation 5 of the paper, but this will
>             take account of the Nomen entity and the function of the
>             URL as an identifier. None of the discussion so far
>             compels me to suggest changing the RDA definition of the
>             URL property.
>
>             As far as I know, none of I, my colleagues developing the
>             RDA Toolkit and Registry, or the intended users of RDA,
>             are in "the state of having a serious mental illness" or
>             exhibiting "extremely foolish behaviour". Rather, it is
>             our intention to avoid, not promote, "a state of wild or
>             chaotic activity" :-)
>
>             Cheers
>
>             Gordon
>
>             *From:*Bibliographic Framework Transition Initiative Forum
>             [mailto:[log in to unmask]]*On Behalf Of*Karen Coyle
>             *Sent:*18 November 2015 05:37
>             *To:*[log in to unmask]
>             <mailto:[log in to unmask]>
>             *Subject:*Re: [BIBFRAME] Properties of Item proposal
>
>             I agree with Jeff. The semantics of the value should be
>             made clear by the property, and not by overloading or
>             masking the type of the value.
>
>             I think the problem is in the property
>             "<rdam:uniformResourceLocator.en>"It should be something
>             more like "rdax:location" if that's what the value means.
>             URL is a kind of thing, not a relationship between
>             entities. "ex:hasURL" (if you want to make it into a verb)
>             is essentially about the the lowest semantics I can
>             imagine. We don't create properties like "ex:string", we
>             create properties that say what the string is about, such
>             as "dct:title" or "skos:label". URL should be the value,
>             not the predicate.
>
>             And if the URL goes to a splash page, well, it goes to a
>             splash page. In line with the conversation we've had with
>             Ray, your metadata can't control what's on the other end,
>             and catalogers are not omniscient nor can they see into
>             the future. What if the URL after a while returns a 404?
>             How can cataloging rules have any control over that?
>
>             I don't think that linked data is going to be any more
>             perfect than unlinked data has been. And I don't think
>             that we should burden humans with decisions about things
>             that are arbitrarily outside of their control. That way
>             lies madness.
>
>             kc
>
>             On 11/17/15 5:54 PM, Jeff Young wrote:
>
>                 I'd say put them all in angle brackets. The ones that
>                 "get it" will rise to the top. The others are easily
>                 sniffed for what they are.
>
>
>                 On Nov 17, 2015, at 5:35 PM, Gordon Dunsire
>                 <[log in to unmask]
>                 <mailto:[log in to unmask]>> wrote:
>
>                     Ray, All
>
>                     I agree; anyone can say anything about any thing.
>                     This is what RDA says:
>
>                     "A Uniform Resource Locator, or URL, is the
>                     address of a remote access resource.
>
>                     Uniform Resource Locators include all resource
>                     identifiers intended to provide online access to a
>                     resource using a standard Internet browser.
>
>                     Take information on Uniform Resource Locators from
>                     any source.
>
>                     Record the Uniform Resource Locator for the online
>                     resource being described.
>
>                     If there is more than one Uniform Resource Locator
>                     for the resource, record one or more according to
>                     the policy of the agency preparing the description.
>
>                     Record a Uniform Resource Locator for a related
>                     resource as part of the description of the related
>                     manifestation."
>
>                     "Resource" here means the RDA/FRBR entity
>                     Manifestation, and nothing else.
>
>                     In practice, the URL recorded may resolve to (get)
>                     an online file constituting the real-world object
>                     that is the resource being described, or it may
>                     resolve to a so-called jump-off page that links to
>                     various related versions/formats of the resource
>                     being described, or it may resolve to an
>                     interactive page such as a page-turner, and so on.
>                     All of these cases are covered by the
>                     instructions, but only the first case allows a
>                     semantically coherent and machine-readable
>                     resolution of the data. Thus I think that the RDA
>                     URL data is non-resolvable (not un-resolvable) in
>                     the context of a coherent linked data application.
>                     It is a similar case to other Manifestation
>                     identifiers, such as ISBN which cannot guarantee,
>                     in principle, that a single number/identifier
>                     refers to one and only one Manifestation.
>
>                     I think it is important to make the distinction.
>                     If the RDA URL is treated as a URI, then what does
>                     the URI identify?
>
>                     Suppose <resource1URI>
>                     <rdam:uniformResourceLocator.en> <URL1> .
>
>                     If <resource1URI> and <URL1> are URIs for the same
>                     Manifestation, then <resource1URI> owl:sameAs
>                     <URL1> . This makes the URL property redundant.
>
>                     If they are URIs for different Manifestations,
>                     then the RDA instructions are clear that the URL
>                     should not be recorded as a value of the URL property.
>
>                     The RDA Steering Committee intends that the data
>                     produced using the RDA instructions and
>                     represented as linked data using the RDA element
>                     sets and value vocabularies are coherent. There is
>                     nothing in this approach that is inconsistent with
>                     RDF or FRBR.
>
>                     Applications are free to interpret the value of
>                     RDA URL as a URI that resolves to a web document;
>                     the RDA property does not declare a range. That
>                     document might be the Manifestation/Item in focus,
>                     or a log-on form, or something else. Applications
>                     can also impose URI functionality on URLs declared
>                     as literals - but RDA data will not guarantee any
>                     consistency in the results.
>
>                     This is the only reason I can come up with for an
>                     application needing to know the provenance, or
>                     anything else, of a URL in this context (was it
>                     the location of some other document in the past?
>                     is it the location of some other document now?).
>                     Using RDF means we don't have to talk about URIs
>                     as identifiers; the provenance of a URI is all the
>                     triples that use it.
>
>                     The RDA approach is evolving to conform to the new
>                     consolidated FRBR model, which introduces the
>                     entity Nomen. We expect the range of an evolved
>                     sub-property of RDA URL (and many other elements
>                     such as titles of works and manifestations, names,
>                     access points, and other identifiers) to be
>                     declared as Nomen, allowing the provenance of any
>                     such identifying string to be recorded as linked
>                     data. The entity has similar semantics and
>                     functionality as skosxl:Label.
>
>                     Cheers
>
>                     Gordon
>
>                     *From:*Bibliographic Framework Transition
>                     Initiative Forum
>                     [mailto:[log in to unmask]]*On Behalf
>                     Of*Denenberg, Ray
>                     *Sent:*17 November 2015 20:20
>                     *To:*[log in to unmask]
>                     <mailto:[log in to unmask]>
>                     *Subject:*Re: [BIBFRAME] Properties of Item proposal
>
>                     Gordon – I suppose RDA is free to define URIs and
>                     URLs, and the distinction between them,  as it
>                     sees fit, since there are already a number of
>                     different views.  But in my opinion, to consider a
>                     URL to be a non-resolvable identifier is a serious
>                     mistake.
>
>                     In my view (just one of many), there is no
>                     substantive difference.  Not that there is NO
>                     difference, but the difference is not worth the
>                     time to agonize over.  When I am discussing a link
>                     with someone unfamiliar in general with Web
>                     terminology, say,  a link on a web page, I use
>                     “URL”. If I say “URI” they have no idea what I’m
>                     talking about.  And the URL I’m discussing with
>                     that person is of course resolvable.  On the other
>                     hand, when discussing linked data, RDF, etc. I say
>                     “URI”; “URL” doesn’t seem to have much meaning in
>                     that context.
>
>                     I recently wrote a brief primer on BIBFRAME RDF
>                     for LC catalogers.  Upon introducing the URI
>                     concept, I said:
>
>                     /“At this point, people usually ask what is the
>                     difference between a URI and URL.  For purposes of
>                     this discussion, there is no substantive
>                     difference whose explanation would be of any
>                     value, so assume they are the same.” /
>
>                     Anyway, that’s how I see it.
>
>                     And I’ll add that if one takes the view that they
>                     are substantially the same, it follows that it
>                     might be a good idea to standardize on one and
>                     drop the other.  And that’s what theWHATWG
>                     <https://urldefense.proofpoint.com/v2/url?u=https-3A__whatwg.org_&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=TM5IhWBVww9Np2U8WFXtuhAw8WFwaWiwd50ijHZ0R_Y&e=>proposes
>                     to do, standardizeURL
>                     <https://urldefense.proofpoint.com/v2/url?u=https-3A__url.spec.whatwg.org_&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=ghmP71XZ69-NLyX4u_QnjRQgHxIPWDgXRHvzRlo_SpE&e=>and
>                     drop URI. Me, I prefer URI, but I won’t fight that
>                     battle.
>
>                     Ray
>
>                     *From:*Bibliographic Framework Transition
>                     Initiative Forum
>                     [mailto:[log in to unmask]]*On Behalf
>                     Of*Gordon Dunsire
>                     *Sent:*Tuesday, November 17, 2015 9:16 AM
>                     *To:*[log in to unmask]
>                     <mailto:[log in to unmask]>
>                     *Subject:*Re: [BIBFRAME] Properties of Item proposal
>
>                     All
>
>                     The JSC Technical Working Group discussed the
>                     issue of URL vs URI in a paper discussed by the
>                     RDA Steering Committee a few days ago;
>                     seehttp://www.rda-jsc.org/sites/all/files/6JSC-TechnicalWG-6.pdf
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rda-2Djsc.org_sites_all_files_6JSC-2DTechnicalWG-2D6.pdf&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=b9VjLU8LrIX5AGFC1pV7IUcf883GdNCrnESWFPFVirA&e=>(page
>                     4 and following). The RSC accepted recommendation
>                     1 and is taking appropriate action.
>
>                     The basic conclusion is that a URI is a thing (RDF
>                     resource), and a URL is a string (non-resolvable
>                     identifier). This is reflected, I think, in the
>                     basic syntax of RDF: a piece of data in quotes is
>                     a string (human-readable) and all other data in a
>                     triple are things (machine-readable URIs). Using
>                     angle-bracket and quote delimiters, the two basic
>                     triple syntaxes are:
>
>                     <subjectURI> <propertyURI> <objectURI> .
>
>                     <subjectURI> <propertyURI> “object string” .
>
>                     I hope this paper is of use – and please let me
>                     know (as Chair of the Working Group) if you
>                     disagree with anything.
>
>                     Cheers
>
>                     Gordon
>
>                     *From:*Bibliographic Framework Transition
>                     Initiative Forum
>                     [mailto:[log in to unmask]]*On Behalf
>                     Of*Denenberg, Ray
>                     *Sent:*16 November 2015 22:19
>                     *To:*[log in to unmask]
>                     <mailto:[log in to unmask]>
>                     *Subject:*Re: [BIBFRAME] Properties of Item proposal
>
>                     Well of course.  You can never guarantee good
>                     behavior of an independent system. I’m only saying
>                     that these are the rules we are supposed to be
>                     playing by.  If I encounter an object of a triple
>                     which looks like an RDF resource URI, I
>                     dereference it (requesting RDF), and you refuse
>                     the request, I’d consider that a failure.
>
>                     Ray
>
>                     *From:*Bibliographic Framework Transition
>                     Initiative Forum
>                     [mailto:[log in to unmask]]*On Behalf
>                     Of*LeVan,Ralph
>                     *Sent:*Monday, November 16, 2015 4:58 PM
>                     *To:*[log in to unmask]
>                     <mailto:[log in to unmask]>
>                     *Subject:*Re: [BIBFRAME] Properties of Item proposal
>
>                     Ray, my VIAF server does provide RDF when asked
>                     via content negotiation.  Today it does.  So,
>                     today triples that have a VIAF URI in them are
>                     legal, but tomorrow when I break content
>                     negotiation they suddenly become illegal?  It’s
>                     impossible for the coiner of the triple to
>                     guarantee some third-party server behavior.  It’s
>                     up to the consumer of the triple to identify those
>                     URIs that are pointers to RDF and do whatever
>                     seems appropriate.
>
>                     Ralph
>
>                     *From:*Bibliographic Framework Transition
>                     Initiative Forum
>                     [mailto:[log in to unmask]]*On Behalf
>                     Of*Denenberg, Ray
>                     *Sent:*Monday, November 16, 2015 4:14 PM
>                     *To:*[log in to unmask]
>                     <mailto:[log in to unmask]>
>                     *Subject:*Re: [BIBFRAME] Properties of Item proposal
>
>                     Karen,  take this one step at a time.  Suppose I
>                     have a triple:
>
>                     <some subject> bf:someProperty   <http://someURI
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__someURI&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=HFPDfnBRcwsrp4unS6Xo04i8sxHFr8j9rbZTYnu5UiQ&e=>>
>
>                     Where again I am using turtle notation and I am
>                     explicitly enclosing http://someURI
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__someURI&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=HFPDfnBRcwsrp4unS6Xo04i8sxHFr8j9rbZTYnu5UiQ&e=> 
>                     in angle braces.   I claim thathttp://someURI
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__someURI&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=HFPDfnBRcwsrp4unS6Xo04i8sxHFr8j9rbZTYnu5UiQ&e=>(enclosed
>                     in angle braces) must be dereferenceable as RDF
>                     (meaning that there is an RDF representation of
>                     that resource,http://someURI
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__someURI&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=HFPDfnBRcwsrp4unS6Xo04i8sxHFr8j9rbZTYnu5UiQ&e=>,
>                     which may be one of many representations, and I
>                     can get that RDF representation by doing a get on
>                     it requesting RDF via content negotiation).
>
>                     Do you not agree?
>
>                     (And you’re saying that “RDF resource” is defined
>                     in the documents you cited, but that expression
>                     doesn’t even occur in any of those documents.
>                     Nowhere. So I’m confused.)
>
>                     Ray
>
>                     *From:*Bibliographic Framework Transition
>                     Initiative Forum
>                     [mailto:[log in to unmask]]*On Behalf
>                     Of*Karen Coyle
>                     *Sent:*Monday, November 16, 2015 3:44 PM
>                     *To:*[log in to unmask]
>                     <mailto:[log in to unmask]>
>                     *Subject:*Re: [BIBFRAME] Properties of Item proposal
>
>                     On 11/16/15 10:37 AM, Denenberg, Ray wrote:
>
>                         Hi Karen – Yes there certainly is a
>                         terminology issue, particularly because the
>                         expression “RDF resource” does not have a
>                         formal definition, anywhere (that I have ever
>                         been able to find).
>
>
>                     Actually, Ray, the quotes I gave you in my email
>                     are indeed the formal definition from the W3C
>                     specifications. There is probably an even more
>                     formal definition somewhere using virtually
>                     unreadable notation, but I think that what the
>                     human-readable documents say is quite clear --
>                     which is that a resource is "anything that an RDF
>                     graph describes" and that it can be either an IRI
>                     or a literal. I agree with you that folks often
>                     refer to IRIs as resources as opposed to literals,
>                     but that's a misnomer. Another way of saying this
>                     is "string vs. thing" but there's probably some
>                     ambiguity in that as well. But most importantly,
>                     as I said below, nowhere have I encountered any
>                     statements that there is any distinction made that
>                     what one obtains upon dereferencing must be "RDF".
>                     In fact, I don't know what that actually means.
>
>                     Yourhttp://hdl.loc.gov/loc.pnp/cph.3g11323
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=60Np5o5w2LNBrurCRpmrvm8WzhaZVENoi-sbuUH-VJ0&e=>,
>                     which very clearly follows the rules for an IRI
>                     (and IRIs do not need to be dereferenceable) is an
>                     IRI. What it does or does not dereference to does
>                     not change that. You can treat an IRI as a literal
>                     string (I don't think there's anything in RDF to
>                     prevent that) -- and therefore indicate that you
>                     don't intend it to be actionable as an IRI.
>                     However, again, your distinction of "imply that
>                     you can retrieve RDF by dereferencing" is not
>                     familiar to me.
>
>                     kc
>
>                     However, whenever I encounter the expression it
>                     seems to be used in the sense that I’m using it.
>                       Which is this:
>
>                     In any RDF triple the object is a literal or an
>                     RDF resource.  A literal is of course a resource;
>                     and I am making a distinction between “resource”
>                     and “RDF resource”.
>
>                     So, the object of a triple is either:
>
>                     1.a literal, in which case it’s enclosed in quotes
>                     (assuming turtle serialization); or
>
>                     2.not enclosed in quotes, in which case it is an
>                     RDF resource URI (either enclosed by curly braces
>                     or using namespace prefix notation), or a blank
>                     node id.
>
>                     For case 2, the URI can be dereferenced resulting
>                     in an RDF description or if it is a blank node it
>                     points to an RDF description.
>
>
>                     Do you agree (so far)?  If you think I’m using the
>                     expression “RDF resource” incorrectly then what is
>                     your definition?  If you think “RDF resource” and
>                     “resource” mean the same thing, I disagree, but
>                     then, I could be wrong, since “RDF resource” has
>                     no formal definition.  But I’m using it in the
>                     sense that I see it used.
>
>                     Anyway, having said all that, getting back to the
>                     example at hand
>
>                      bf:electronicLocator  [
>
>                             a    bf:ElectronicLocator ;
>
>                          rdf:value
>                       “http://hdl.loc.gov/loc.pnp/cph.3g11323”
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323-25E2-2580-259D&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=xcWpK_Jle-tIFh5wBnZ8en7M7WmOK4R0ttx2CKSAc-E&e=>]
>                     ;
>
>                     I maintain that it would be incorrect to instead say:
>
>                     bf:electronicLocator
>                      <http://hdl.loc.gov/loc.pnp/cph.3g11323”
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323-25E2-2580-259D&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=xcWpK_Jle-tIFh5wBnZ8en7M7WmOK4R0ttx2CKSAc-E&e=>>
>
>                     because that would imply that you can retrieve RDF
>                     by
>                     dereferencinghttp://hdl.loc.gov/loc.pnp/cph.3g11323 <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=60Np5o5w2LNBrurCRpmrvm8WzhaZVENoi-sbuUH-VJ0&e=>,
>                     which (as far as I know) you can’t.
>
>                     Ray
>
>                     *From:*Bibliographic Framework Transition
>                     Initiative Forum
>                     [mailto:[log in to unmask]]*On Behalf
>                     Of*Karen Coyle
>                     *Sent:*Sunday, November 15, 2015 8:30 PM
>                     *To:*[log in to unmask]
>                     <mailto:[log in to unmask]>
>                     *Subject:*Re: [BIBFRAME] Properties of Item proposal
>
>                     On 11/12/15 12:05 PM, Denenberg, Ray wrote:
>
>                         Hi Joseph – thanks for the comments and
>                         questions.  I want to address two points,
>                         while we are still discussing the other
>                         suggestions.
>
>                         bf:electronicLocator is, at present, conceived
>                         to be a datatype property; its expected value
>                         is a literal.  We could change that to an
>                         object property if that’s what people want,
>                         however, the URI would still be a literal,
>                         because it is not an RDF resource.   In the
>                         example, the electronic locator
>                         ishttp://hdl.loc.gov/loc.pnp/cph.3g11323
>                         <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=60Np5o5w2LNBrurCRpmrvm8WzhaZVENoi-sbuUH-VJ0&e=>and
>                         this is not an RDF resource. (By RDF resource,
>                         we mean, you can dereference the URI and get
>                         RDF in response. You can’t for this URI.)
>
>
>                     Ray, can you say more about this concept of a
>                     non-resource? AFAIK, many URIs do not dereference
>                     to  "RDF in response", but they are still
>                     considered resources in RDF. I'm looking at:
>
>                     "90.Resource
>                     In an RDF context, a resource can be anything that
>                     an RDF graph describes. A resource can be
>                     addressed by aUnified Resource Identifier (URI)
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_2013_NOTE-2Dld-2Dglossary-2D20130627_-23uniform-2Dresource-2Didentifier&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=pJxh8Ddk2IAmQsrxpT17T2LYGVGoMqopZpI3Bzk280I&e=>."
>                     [1]
>
>                     "AnyIRI
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_rdf11-2Dconcepts_-23dfn-2Diri&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=-WsiTeyEcKqj9rQjv5n-jdjCcxJYFZacGcgxMt1N_pc&e=>orliteral
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_rdf11-2Dconcepts_-23dfn-2Dliteral&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=XHJdSFgGL3kAk3ooq000N_Gqvr-95gXTW_9NILEslgw&e=>*denotes*something
>                     in the world (the "universe of discourse"). These
>                     things are called*resources*. Anything can be a
>                     resource, including physical things, documents,
>                     abstract concepts, numbers and strings; the term
>                     is synonymous with "entity" as it is used in the
>                     RDF Semantics specification [RDF11-MT
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_rdf11-2Dconcepts_-23bib-2DRDF11-2DMT&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=Huj7eJIqck1aGkwaZYluHByn0km_fkWrFuUBWwjMo9k&e=>]."[2]
>
>                     There is similar language in the RDF 1.1 primer. [3]
>
>                     This might be a terminology issue, but even
>                     accepting a different terminology, I'm not aware
>                     of any distinction where a response to the
>                     dereferencing of an IRI must be RDF (meaning?
>                     ntriples? JSON-LD?) rather than any RDF:resource
>                     (e.g. a jpeg file, an html file, an avi file).
>
>                     kc
>                     [1]http://www.w3.org/TR/2013/NOTE-ld-glossary-20130627/#resource
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_2013_NOTE-2Dld-2Dglossary-2D20130627_-23resource&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=vkTyy9_pYDC52FSwlUT-Sl9Yjq41Q2pZwgGy0hjr07I&e=>
>                     [2]http://www.w3.org/TR/rdf11-concepts/#resources-and-statements
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_rdf11-2Dconcepts_-23resources-2Dand-2Dstatements&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=xxtN1uLkUFzmqhBCzxKrkeO5d7aWXyP5RhU9R-odIfQ&e=>
>                     [3]http://www.w3.org/TR/rdf11-primer/
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_TR_rdf11-2Dprimer_&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=tE8IeGbnF-ks7ZXWR46fW4i18zlssXoseqppMNKonKM&e=>
>
>                     If bf:electronicLocator were to be redefined as an
>                     object property, then instead of this:
>
>                     <http://bibframe.example.org/item/item5>
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__bibframe.example.org_item_item5&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=YS_oDur7NszjtGPy18vd2nAFa1F76tNsSg2O3-90teE&e=>
>
>
>                               a bf:Item ;
>
>                     bf:electronicLocator
>                     “http://hdl.loc.gov/loc.pnp/cph.3g11323”
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323-25E2-2580-259D&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=xcWpK_Jle-tIFh5wBnZ8en7M7WmOK4R0ttx2CKSAc-E&e=>
>                     ;
>
>                     ……
>
>                     It might look like this:
>
>                     <http://bibframe.example.org/item/item5>
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__bibframe.example.org_item_item5&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=YS_oDur7NszjtGPy18vd2nAFa1F76tNsSg2O3-90teE&e=>
>
>
>                               a bf:Item ;
>
>                     bf:electronicLocator  [
>
>                     a    bf:ElectronicLocator ;
>
>                        rdf:value
>                       “http://hdl.loc.gov/loc.pnp/cph.3g11323”
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__hdl.loc.gov_loc.pnp_cph.3g11323-25E2-2580-259D&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=xcWpK_Jle-tIFh5wBnZ8en7M7WmOK4R0ttx2CKSAc-E&e=>]
>                     ;
>
>                     ……
>
>                     Where here we now have defined class
>                     bf:ElectronicLocator, but the URI is still a literal.
>
>                     Second, should bf:itemOf (property of item) have a
>                     reciprocal property, bf:hasItem (property of
>                     Instance).
>
>                     I don’t know; opinions are welcomed on this
>                     question.  We did not include it in the draft for
>                     this reason: an item knows (or should know) what
>                     Instance it is an Item of. An Instance in general
>                     does not know the existence of all items that
>                     claim to be an item of that Instance. So if there
>                     were to be a property bf:hasItem, it could be used
>                     within an Instance to point to all items that that
>                     Instance knows about with the disclaimer that it
>                     doesn’t claim to point to all its items. If, as
>                     such, this would be useful then we can add the
>                     property.  (The same dilemma applies to instanceOf
>                     and hasInstance. And granted, these are both
>                     included in BIBFRAME 1.0.)
>
>                     Ray
>
>                     **
>
>                     *From:*Bibliographic Framework Transition
>                     Initiative Forum
>                     [mailto:[log in to unmask]]*On Behalf
>                     Of*Joseph Kiegel
>                     *Sent:*Tuesday, November 10, 2015 1:39 PM
>                     *To:*[log in to unmask]
>                     <mailto:[log in to unmask]>
>                     *Subject:*[BIBFRAME] Properties of Item proposal
>
>                     Items in BIBFRAME may serve different purposes,
>                     which is not addressed in the Items proposal.  A
>                     relatively narrow purpose is to support the user
>                     task/obtain/, while a more complex one is to
>                     support a working circulation system.  The
>                     properties elaborated in the proposal are not
>                     sufficient even for the user task/obtain/.  Here
>                     are comments on them.
>
>                     bf:electronicLocator: should the expected value be
>                     a URI?  It seems odd to express URLs as literals
>                     in linked data.
>
>                     bf:heldBy and bf:subLocation: the MARC holdings
>                     format and many library systems recognize three
>                     levels of location information: organization,
>                     library and sublocation within a library. BIBFRAME
>                     should support the same number of levels:  for
>                     example, it should add a property such as
>                     bf:location, which is intermediate between
>                     bf:heldBy and bf:subLocation.
>
>                     bf:heldBy University of Washington Libraries
>
>                     bf:location: Art Library
>
>                     bf:subLocation: Reference stacks
>
>                     bf:heldBy University of Washington Libraries
>
>                     bf:location: Engineering Library
>
>                     bf:subLocation: Reference stacks
>
>                     Without bf:location, reference or general stacks
>                     locations in different buildings appear to be the
>                     same.
>
>                     bf:itemOf: is a reciprocal property needed? For
>                     example, bf:hasItem, a property of bf:Instance
>                     with an expected value of bf:Item.
>
>                     Two properties are lacking from the proposal:
>                     bf:itemStatus and bf:circulationCharacteristic
>
>                     bf:itemStatus: it is crucial to inform users of
>                     the status of an item, e.g. available, checked
>                     out, missing, withdrawn, at the bindery, etc.
>
>                     bf:circulationCharacteristic: another important
>                     aspect of materials is the general policy that
>                     governs them, e.g. circulating or library use
>                     only.  It is tempting to try to include this
>                     characteristic in bf:itemStatus, but they are
>                     independent aspects.  LUO materials may be
>                     missing, at the bindery or even checked out (e.g.
>                     faculty loans of reference materials).
>
>                     -- 
>
>                     Karen Coyle
>
>                     [log in to unmask] <mailto:[log in to unmask]>  http://kcoyle.net
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__kcoyle.net&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=3D7J3INr3nKlknCbiQK-C28KZMnM0j9zPDwzxFo4lnc&e=>
>
>                     m: +1-510-435-8234
>
>                     skype: kcoylenet/+1-510-984-3600
>
>                     -- 
>
>                     Karen Coyle
>
>                     [log in to unmask] <mailto:[log in to unmask]>  http://kcoyle.net
>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__kcoyle.net&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=3D7J3INr3nKlknCbiQK-C28KZMnM0j9zPDwzxFo4lnc&e=>
>
>                     m: +1-510-435-8234
>
>                     skype: kcoylenet/+1-510-984-3600
>
>
>
>
>             -- 
>
>             Karen Coyle
>
>             [log in to unmask] <mailto:[log in to unmask]>
>             http://kcoyle.net
>             <https://urldefense.proofpoint.com/v2/url?u=http-3A__kcoyle.net&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=96Yl7NayWcMu7tyqDmXW25XSKg4bTG0oZW8dP5LX1wU&m=FDQbMbqNhO_8LKnaJk8Z0BLsjYLodwwQYkLA_rtU2_4&s=3D7J3INr3nKlknCbiQK-C28KZMnM0j9zPDwzxFo4lnc&e=>
>
>             m: +1-510-435-8234
>
>             skype: kcoylenet/+1-510-984-3600
>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600