Re: Re: what happened to Wikipedia COinS?

what happened to Wikipedia COinS?

COinS implementors. Please tell us if you want your COinS rendered!

LibX renders COinS, typically as icons that provide links to OpenURL
resolvers. We're currently making them a lot smarter by using services
such Summon to tell an interacting user more about the availability of
the referred-to item.

We are regularly getting requests from LibX maintainers and users to
suppress COinS on certain pages where the COinS is placed in a way
that disrupts the layout of the page.

vufind is a big offender.

The most prominent COinS processors are probably Zotero & LibX. Zotero
doesn't render them and thus doesn't care where they are. We do.

The spec says:

"Since an important use of this metadata will be to allow processing
agents to make OpenURL hyperlinks for users in libraries (latent
OpenURL), the method must allow the metadata to be placed any where in
HTML that a link might appear."

Proposal:

As a COinS provider, please provide us with guidance if you want your
COinS rendered or not.

If you don't, simply place it in an invisible container or add
style="display: none" and we'll respect it.

If you do, please place it somewhere in your DOM where inserting a,
say 16x16 image is not disruptive.

Perhaps the spec could be extended to make that clear. Perhaps:

"Since an important use of this metadata will be to allow processing
agents to make OpenURL hyperlinks for users in libraries (latent
OpenURL), the method should allow the metadata to be placed any where
in HTML that a link might appear. If the placement of such links is
not desired, the metadata should be placed in a context that is
invisible by adding a style="display: none" to the <span> element."

And please fix vufind.

Thank you.

 - Godmar

--

-- 
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en.

unapi example?

Hi,

I'm trying to understand the unAPI spec:
http://unapi.info/specs/

The example (under 'complete example') at that page says:
"Compose the unAPI base URL, weblog entry identifier, and the oai_dc
FORMAT by visiting http://unapi.info/news/unapi.php?id=http://unapi.info/news/archives/9&format=oai_dc
to see a Dublin Core record for the entry in the OAI-PMH schema for
Dublin Core data."

However, http://unapi.info/news/unapi.php gives a 404.

Should this be updated? And, by the way, any suggestion for a short
complete example of the markup required?
-Jodi

--

-- 
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en.

how to use unapi for bibtex files

I have a website with bibtex files (that get converted to html via
php). I would like to use unAPI so that a program like zotero can get
the info from my site. Is there an easy way to do this that doesn't
involve reprogramming my php parser? Like a way to get the unAPI info
straight from the bibtex files?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en
-~----------~----~----~----~------~----~------~--~---

RDFa OpenURL

In a recent session at the Semantic Technology Conference in San Jose,
People from google indicated that they would be interested to pick up
article citation information from web pages if it was incoded in RDFa.
Since there is no RDF binding for OpenURL, and since it would be
straightforward to produce one, I wonder if anyone is interested in
helping me to do that.

Eric
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en
-~----------~----~----~----~------~----~------~--~---

One Data Format Identifier (and Registry) to Rule Them All

Hello everybody.  I apologize for the crossposting, but this is an
area that could (potentially) affect every one of these groups.  I
realize that not everybody will be able to respond to all lists,
but...

First of all, some back story (Code4Lib subscribers can probably skip ahead):

Jangle [1] requires URIs to explicitly declare the format of the data
it is transporting (binary marc, marcxml, vcard, DLF
simpleAvailability, MODS, EAD, etc.).  In the past, it has used it's
own URI structure for this (http://jangle.org/vocab/formats#...) but
this was always been with the intention of moving out of the
jangle.org into a more "generic" space so it could be used by other
initiatives.

This same concept came up in UnAPI [2] (I think this thread:
http://old.onebiglibrary.net/yale/cipolo/gcs-pcs-list/2006-March/thread.html#682
discusses it a bit - there is a reference there that it maybe had come
up before) although was rejected ultimately in favor of an (optional)
approach more in line with how OAI-PMH disambiguates metadata formats.
 That being said, this page used to try to set sort of convention
around the UnAPI formats:
http://unapi.stikipad.com/unapi/show/existing+formats
But it's now just a squatter page.

Jakob Voss pointed out that SRU has a schema registry and that it
would make sense to coordinate with this rather than mint new URIs for
things that have already been defined there:
http://www.loc.gov/standards/sru/resources/schemas.html

This, of course, made a lot of sense.  It also made me realize that
OpenURL *also* has a registry of metadata formats:
http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats

The problem here is that OpenURL and SRW are using different info URIs
to describe the same things:

info:srw/schema/1/marcxml-v1.1

info:ofi/fmt:xml:xsd:MARC21

or

info:srw/schema/1/onix-v2.0

info:ofi/fmt:xml:xsd:onix

The latter technically isn't the same thing since the OpenURL one
claims it's an identifier for ONIX 2.1, but if I wasn't sending this
email now, eventually SRU would have registered
info:srw/schema/1/onix-v2.1

There are several other examples, as well (MODS, ISO20775, etc.) and
it's not a stretch to envision more in the future.

So there are a couple of questions here.

First, and most importantly, how do we reconcile these different
identifiers for the same thing?  Can we come up with some agreement on
which ones we should really use?

Secondly, and this gets to the reason why any of this was brought up
in the first place, how can we coordinate these identifiers more
effectively and efficiently to reuse among various specs and
protocols, but not:
1) be tied to a particular community
2) require some laborious and lengthy submission and review process to
just say "hey, here's my FOAF available via UnAPI"
3) be so lax that it throws all hope of authority out the window
?

I would expect the various communities to still maintain their own
registries of "approved" data formats (well, OpenURL and SRU, anyway
-- it's not as appropriate to UnAPI or Jangle).

Does something like this interest any of you?  Is there value in such
an initiative?

Thanks,
-Ross.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en
-~----------~----~----~----~------~----~------~--~---

COinS generator missing

The COinS generator which was at <http://generator.ocoins.info/> seems
to have disappeared, that URL now serves the content also found at
<http://nj.oclc.org/>.

Anyone know why?

--

-- 
Andy Mabbett
            Says  "NO! to compulsory UK ID Cards":  <http://www.no2id.net/>
            and:  "Free Our Data":  <http://www.freeourdata.org.uk>
                   (both also on Facebook)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en
-~----------~----~----~----~------~----~------~--~---

UnAPI formats list

Hey everybody.

I'm trying to write a little UnAPI adapter for Jangle, but I'm a
little hung up on the part of the spec that defines which formats are
available by the service (the "no arguments passed" part).  The spec
reads:

"Provide a list of object formats which should be supported for all
objects available through the unAPI service."

So, this reads like "every identifier that gets passed to the UnAPI
service can be returned in any of the formats listed".  Is that
correct?  It's like the opposite of OAI-PMH's ListMetadataFormats
verb, which names every possible metadata format, but not all
identifiers may be available in said format.

I can't find the gcs-pcs archives (although, admittedly, I didn't look
very hard) to try to track down where we discussed this.

Thanks,
-Ross.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en
-~----------~----~----~----~------~----~------~--~---

Java implementation of unAPI HTTP service available

FYI, I've released a Java implementation of the unAPI HTTP service to
Sourceforge:
http://funapi.sf.net/. This release provides unAPI support for both
Fedora and DSpace and it should be fairly easy to add implementations
that support other services as well, in particular for services that
support OAI-PMH.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en
-~----------~----~----~----~------~----~------~--~---

Jangle version 1.0 draft specification now available for review and comment

Hi everybody.  Pardon the cross-posting.

Jangle, an open specification to apply the Atom Publishing Protocol to
library services and resources, has just released a draft version of a
1.0 release spec.

http://jangle.org/drupal/1_0rev1spec

The goal of Jangle is to provide a very simple and easily
understandable RESTful interface to library data that can be accessed
with common commodity Atom clients.

The draft spec has been released to get feedback on the usefulness and
clarity of the specification and to solicit ideas for how to improve
Jangle for use in actual production environments.  If you have any
opinions, positive or negative; criticisms, constructive or otherwise,
feel free to leave comments.

Grammar and sentence structure could definitely use attention.

For a more in-depth introduction to Jangle, there is an article in the
latest issue of the Code4Lib Journal, "Unveiling Jangle: Untangling
Library Resources and Exposing them through the Atom Publishing
Protocol" available at:  http://journal.code4lib.org/articles/109
(although the API responses have changed since this article was
written, the basic architecture remains the same).

To join the Jangle development process, feel free to join our Google
Group at:  http://groups.google.com/group/jangle-discuss or contribute
to the development at:  http://code.google.com/p/jangle/

Thanks!
-Ross.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "gcs-pcs-list" group.
To post to this group, send email to gcs-pcs-list@...
To unsubscribe from this group, send email to gcs-pcs-list+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/gcs-pcs-list?hl=en
-~----------~----~----~----~------~----~------~--~---