- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 10 Dec 2013 10:25:55 -0800
- To: corey.harper@nyu.edu
- CC: Ross Singer <ross.singer@talis.com>, "public-schemabibex@w3.org" <public-schemabibex@w3.org>
If anyone has any useful *ideas*, rather than complaints, about the minimal proposal, I suggest that you create a such proposal on the wiki. That was its purpose. HOnestly, this is a waste of time as a discussion, and so far I haven't seen anything usable come out of it. You don't need to convince me, you need to show the group an alternate proposal. kc On 12/10/13, 9:40 AM, Corey A Harper wrote: > Karen, et al., > > I'm confused by this, still. I don't understand how volume and issue can > be properties of periodical. If that were the case, you'd have an > identifier for a periodical, and you would say that it's volume 12, > issue 3. You then have another with volume 12, issue 4? Same identifier, > or do you need a new one? If the former, than you've just said issue 3 > and issue 4 are the same. > > I think the cleaner way to describe what you're suggesting is to have a > citation, and leave the periodical, issuance, issue, volume, publisher > and the rest _as entities_ out of it. That's something that can easily > be done, and that I would get behind. You could even have an identifier > for that citation, and have representations of it that are nothing but > strings all the way down, allowing another system use that same > identifier for a citation that uses Dan's more complex representation. > > Such an approach would be less at odds with what Dan, et al, are > proposing. This was the point I was trying to make on the last call: > these proposals don't need to be at odds. They can be complimentary. I > think we need to unpack this in a way that's less at cross-purposes. > > You say, "I consider the simple case the be the majority case". I --and > most of the others on this thread, I think-- disagree. Perhaps the > majority case in terms of number of people / systems creating markup. > Likely not the majority case in number of citations represented. Many of > us are trying to go at this from the perspective of large-scale, > database-driven, data management systems. I feel like Dan's proposal is > more appropriate for those of us who _do_ have more fully normalized > data, who do have the equivalent of series authority data, who are using > and developing systems like Koha; Ex Libris' Aleph, Alma, Primo; > WorldCat; BlackLight, the Grand Comics Database, etc, and who will > generate this markup through templates that will be applied across > thousands if not hundreds of thousands of records. Why should that > use-case be _forced_ to flatten that data into a series of un-typed > strings? You could ask a similar question of Dan's proposal, which > currently doesn't leave many options for the individual marking up the > data on their Web-page without the aid of a bunch of MVC-based abstraction. > > I'd really like to find a way forward that supports all of these > use-cases rather than have this silly back & forth calling into question > one-another's use-cases. > > Regards, > -Corey > > > On Tue, Dec 10, 2013 at 12:17 PM, Karen Coyle <kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> wrote: > > Ross, it's SHOULD not MUST, and the header is "expected type" -- but > in discussions w DanBri and others, they admit that they aren't > considering other input invalid. However, I consider this digression > irrelevant to what matters in this discussion. > > Yes, periodical volume and periodical issue are generally strings. I > still think that volume and issue can be properties of Periodical in > a simple scheme that works for markup of the vast majority of web > pages with article information. I do NOT think that trying to > replicate the complex structure of periodical publication serves the > simple case, and I consider the simple case the be the majority > case. This simple approach works for: RIS, BIBTEX, Endnote, > Mendeley, Zotero, the PRIMO display, and others. That's my view. > > kc > > > > > On 12/10/13, 8:56 AM, Ross Singer wrote: > > I think what I'm trying to say is that I don't understand what > you're > proposing the intended domains for "volume" and "issue" to be. > In your > example, they're strings. I don't think this is splitting hairs > to say > it would make something like > http://www.nature.com/nature/__archive/index.html > <http://www.nature.com/nature/archive/index.html> extremely awkward. > > The schema.org <http://schema.org> <http://schema.org> > documentations says > > > each property may have one or more types as its ranges. The > value(s) > of the property should be instances of at least one of > these types. [1] > > > That seems, to me, a little stronger than a suggestion. > > But I don't see how asking for the range of > Periodical#issue/issues to > be PeriodicalIssue is fundamentally any different than how > Series/Episode is currently designed. > > -Ross. > 1. http://schema.org/docs/__datamodel.html > <http://schema.org/docs/datamodel.html> > > > On Tue, Dec 10, 2013 at 11:27 AM, Karen Coyle <kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> wrote: > > > > On 12/10/13, 3:28 AM, Ross Singer wrote: > > By "elsewhere" I mean PeriodicalIssue. > > In your Series example, the range of episode/episodes is > http://schema.org/Episode > > In your proposal, aren't these strings? > > > Yes, but as you know, ranges in schema are suggested, not > required. > Really, I think a lot of hairs are being split here, given the > actual goals. > > kc > > > -Ross. > > On Dec 10, 2013 12:37 AM, "Karen Coyle" > <kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>> wrote: > > > > On 12/9/13, 6:33 PM, Ross Singer wrote: > > > Karen, can you extrapolate why you think it > would be a > journal > property? > > It seems to me that journal hasMany > volumes/issues, > which would put > these properties elsewhere. > > > Hmmm. I'm not sure what you mean by "elsewhere." The > periodical is > something that is published over time in discrete > parts, > and the > serially published parts are usually in the form > of volumes > (that > are usually temporal, e.g. they represent a year of > publication) and > issues (that are the serial "manifestations", numbered > subordinate > to the volume, and with a physical presence). It > is a kind of > whole/part relationship. However, it is a whole/part > relationship > that has a great deal of variation, so no one > pattern will > work for > periodicals in general. In other words, we've got > to fudge > it somewhere. > > However, I think that your point is that the > metadata has > to have > the same structure as the periodical. I'm saying > that doing > so 1) is > not necessary for the schema.org > <http://schema.org> <http://schema.org> > <http://schema.org> markup use case > > and 2) will not be possible without great > complication and 3) > schema.org <http://schema.org> <http://schema.org> > <http://schema.org>, with its > > flat namespace, in any case > > will not reproduce the periodical structure > without making the > periodical schema very complicated. > > I think we can do periodical in a way that is > analogous to > http://schema.org/Series, which has the properties "season" and > "episode" where episode is one instance within a > season > within a series. > > kc > > > > > > > -Ross. > > > > kc > > > > > >> > >> -Ross. > >> > >> > >> kc > >> > >> > >> > >> -Ross. > >> > >> > >> On Mon, Dec 9, 2013 at 1:40 PM, > Karen Coyle > <kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>> > >> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>>>>> > >> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>>>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>>>>__> wrote: > >> > >> > >> > >> On 12/9/13, 9:45 AM, Dan > Scott wrote: > >> > >> > >> Properties that > obviously cross > different classes, > >> IMO, need > >> a general home. > >> Someone marking up book > chapters may > not think to > >> look in > >> Periodical or > >> Article for pagination > patterns. (I've > talked with > >> DanBri > >> about this, but > >> schema desperately > needs a good > visualization > that is > >> graph-oriented, not > >> hierarchical.) > >> > >> > >> I think the mechanism is to > simply add a > domainIncludes > >> declaration > >> for each property of > interest > pointing at > the type (for > >> example, > >> BookChapter, if it gets > defined).. > >> > >> > >> Which one could have done with > MedicalArticle > in order to > >> make use > >> of citation. So either one > takes the > view that > you only > need > >> domainIncludes, or that the > structure > matters, not > >> sometimes one > >> way, some times the other. > >> > >> Honestly, I think that > schema.org <http://schema.org> > <http://schema.org> > <http://schema.org> <http://schema.org> > <http://schema.org> > >> <http://schema.org> itself hasn't > >> > >> made this decision -- which > is why we > end up > looking at it > >> in both > >> ways. Since "the mechanism > is simply > to add a > domainIncludes > >> declaration..." as a technical > solution, I > like to look at > >> what will > >> help people using schema.org > <http://schema.org> > <http://schema.org> > <http://schema.org> <http://schema.org> > <http://schema.org> > >> <http://schema.org> as a strong > >> > >> motivator for decisions. > It's still a > crap > shoot, I admit. > >> > >> > >> > >> I'll admit to being > surprised at > the idea > of adding a > >> Pagination > >> class; that seems like a > much > less useful > thing to > >> potentially > >> link to > >> than an individual > issue. And > there is no > complexity in > >> the pages / > >> startPage / endPage > properties > that binds > their > >> relationship > >> (vs. say > >> a Contributor class that > would > let one > encode or > >> encapsulate the > >> nature of the contribution, > rather than > requiring every > >> possible > >> type > >> of contributor to become > its own > property). > >> > >> > >> I don't know what you mean > by "every > possible > type of > >> contributor to > >> become its own property" but the > reason that I > have for > moving > >> pagination out of periodical > is that > it is > also useful for > >> book/book > >> chapter, unless you expect > people to > domainIncludes Book to > >> Periodical. That, I think, > would not > occur to > many people. > >> > >> > >> > >> FWIW, I originally > wanted to name the > "pagination" > property > >> "pages" or > >> "pageNumbers", but > balked because > schema.org <http://schema.org> <http://schema.org> > <http://schema.org> > <http://schema.org> > >> <http://schema.org> > <http://schema.org> > >> > >> > >> has deprecated most of > >> the plural attribute > names in > favour of > the singular. > >> That said, > >> in my > >> research last week > checking the > MLA and > APA style > >> manuals, "page > >> numbers" was the most > commonly > used term > between > the two, > >> followed by > >> "pagination". So I would > suggest > either > "pageNumbers" or > >> "pagination". > >> This would avoid any > possible > terminology > conflict with > >> "page(s)" as > >> in the assistants to > members of > parliament, or (heh) > >> > people-typically-teenagers who > shelve books at > libraries. > >> > >> > >> Both pageNumbers and > pagination sound > fine. > >> > >> > >> > >> > >> But given that > you want > Periodical > to be a > >> subclass of > >> Series, > >> shouldn't that line > reflect that > deeper > nesting and > >> actually look like > >> the following? > >> > >> Thing > > CreativeWork > > Series > > Periodical > > >> Article > >> > >> > >> > >> I have no idea what > Series > means in > relation to > >> Periodical, > >> and hadn't > >> included it in my > proposal. > >> > >> > >> > http://www.w3.org/community/__________schemabibex/wiki/____Periodical_______Article_____minimal > <http://www.w3.org/community/________schemabibex/wiki/__Periodical_______Article___minimal> > > <http://www.w3.org/community/________schemabibex/wiki/__Periodical_______Article___minimal > <http://www.w3.org/community/______schemabibex/wiki/Periodical_______Article_minimal>> > > > <http://www.w3.org/community/________schemabibex/wiki/____Periodical_____Article_minimal > <http://www.w3.org/community/______schemabibex/wiki/__Periodical_____Article_minimal> > > <http://www.w3.org/community/______schemabibex/wiki/__Periodical_____Article_minimal > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal>__>__> > > >> > > > <http://www.w3.org/community/________schemabibex/wiki/____Periodical_____Article_minimal > <http://www.w3.org/community/______schemabibex/wiki/__Periodical_____Article_minimal> > > > <http://www.w3.org/community/______schemabibex/wiki/__Periodical_____Article_minimal > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal>__> > > > <http://www.w3.org/community/______schemabibex/wiki/__Periodical_____Article_minimal > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal> > > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal > <http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal>>>> > >> > >> > >> > >> > > > <http://www.w3.org/community/________schemabibex/wiki/____Periodical_____Article_minimal > <http://www.w3.org/community/______schemabibex/wiki/__Periodical_____Article_minimal> > > > <http://www.w3.org/community/______schemabibex/wiki/__Periodical_____Article_minimal > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal>__> > > > <http://www.w3.org/community/______schemabibex/wiki/__Periodical_____Article_minimal > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal> > > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal > <http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal>>> > >> > > > <http://www.w3.org/community/______schemabibex/wiki/__Periodical_____Article_minimal > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal> > > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal > <http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal>> > > > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal > <http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal> > > <http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal > <http://www.w3.org/community/schemabibex/wiki/Periodical_Article_minimal>>>>> > >> is the right page for me > to be > looking at, > right? If > >> so, there's a > >> section at the top that > says: > >> > >> """ > >> Subclass Periodical to > Series > >> > >> Thing > CreativeWork > > Series > >> > >> Periodical will also > need to be > sub-classed to Series > >> to make > >> use of... > >> """ > >> > >> This is why I thought > you want > Periodical > to be a > >> sublass of Series. > >> > >> > >> Ah, yes. I'd forgotten that > the start > and end > dates were in > >> Series. > >> I also suggest further down > in the > Intangible > area that > perhaps > >> those should be moved to > Intangible > since that > was one > of those > >> opportunistic subclassings > that I find so > illogical. So it > >> again > >> brings up the question of > whether > there is any > logic to > >> schema.org <http://schema.org> > <http://schema.org> <http://schema.org> > <http://schema.org> > <http://schema.org> > >> <http://schema.org> or if > one simply > wants to > subclass > >> promiscuously > >> > >> to get whatever properties > one needs. > I can go > with > either some > >> semblance of logical > arrangement or > treating > schema.org <http://schema.org> <http://schema.org> > <http://schema.org> > <http://schema.org> > >> <http://schema.org> > >> <http://schema.org> as a flat > vocabulary (and > doing a > lot of > >> > >> opportunistic subclassing) > but being > on the > pendulum > >> between them > >> gives me whiplash. I think > this is a > problem > that many are > >> having > >> with schema, and unfortunately I > don't see it > getting > >> cleared up any > >> time soon. We should > probably just > decide what > our goals > >> are and not > >> worry too much about the > whole. (I > think this > is what the > >> medical > >> folks did.) > >> > >> kc > >> > >> > >> > >> I see them as > bibliographically > distinct, for > >> reasons that I > articulated to > Antoine > a while back. > >> Although > >> series and > >> periodical share the > use of > volume > numbers, I > wouldn't > >> consider a periodical > >> a type of series, for my > bibliographic > concept of > >> series. > >> > >> > >> Okay. > >> > >> If, as you say > >> above, the structure in > schema isn't > significant, > >> then this > >> deeper nesting, > >> IMO, isn't > necessary, and yet > sends > the message > >> that the > >> structure IS > >> significant. This, > again, is a > contradiction within > >> schema > >> that encourages > >> structure yet > ignores it. > >> > >> > >> I don't think I said, > and did not > mean to > imply in any > >> way, that the > >> structure in schema is not > significant. I > was just > >> trying to > >> point out > >> the domainIncludes > approach to go > along > with the > >> subclass option. > >> > >> Thanks, > >> Dan > >> > >> > >> -- > >> Karen Coyle > >> kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>>> > >> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>>>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>>>> > >> http://kcoyle.net > >> m: 1-510-435-8234 > <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>> > <tel:1-510-435-8234 <tel:1-510-435-8234> <tel:1-510-435-8234 > <tel:1-510-435-8234>>> > <tel:1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>> > <tel:1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>>>> <tel:1-510-435-8234 > <tel:1-510-435-8234> > > <tel:1-510-435-8234 <tel:1-510-435-8234>> > <tel:1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>>> > >> > >> <tel:1-510-435-8234 > <tel:1-510-435-8234> <tel:1-510-435-8234 <tel:1-510-435-8234>> > <tel:1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>>>>> > > >> skype: kcoylenet > >> > >> > >> > >> -- > >> Karen Coyle > >> kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>>> > http://kcoyle.net > >> m: 1-510-435-8234 > <tel:1-510-435-8234> <tel:1-510-435-8234 <tel:1-510-435-8234>> > <tel:1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>>> > <tel:1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>> > <tel:1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>>>> > >> skype: kcoylenet > >> > >> > > > > -- > > Karen Coyle > > kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>> > http://kcoyle.net > > m: 1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>> > <tel:1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>>> > > skype: kcoylenet > > > -- > Karen Coyle > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > http://kcoyle.net > m: 1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>> <tel:1-510-435-8234 > <tel:1-510-435-8234> > > <tel:1-510-435-8234 <tel:1-510-435-8234>>> > skype: kcoylenet > > > -- > Karen Coyle > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > http://kcoyle.net > m: 1-510-435-8234 <tel:1-510-435-8234> <tel:1-510-435-8234 > <tel:1-510-435-8234>> > skype: kcoylenet > > > > -- > Karen Coyle > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net > m: 1-510-435-8234 <tel:1-510-435-8234> > skype: kcoylenet > > > > > -- > Corey A Harper > Metadata Services Librarian > New York University Libraries > 20 Cooper Square, 3rd Floor > New York, NY 10003-7112 > 212.998.2479 > corey.harper@nyu.edu <mailto:corey.harper@nyu.edu> -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Received on Tuesday, 10 December 2013 18:26:33 UTC