Download the PHP package scriptotek/marc without Composer

On this page you can find all versions of the php package scriptotek/marc. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package marc

Coverage StyleCI Code Climate Latest Stable Version Total Downloads

scriptotek/marc

This package provides a simple interface to work with MARC21 records using the excellent File_MARC and MARCspec packages. It doesn't do any of the heavy lifting itself, but instead

If you don't need any of this, you might want to use File_MARC directly instead.

Want to contribute to this project? Please see CONTRIBUTING.md.

Installation using Composer:

If you have Composer installed, the package can be installed by running

Reading records

Use Collection::fromFile, Collection::fromString or Collection::fromSimpleXMLElement to read one or more MARC records from a file or string. The methods autodetect the data format (Binary XML or MARCXML) and whether the XML is namespaced or not.

The $collection object is an iterator. If you rather want a normal array, for instance in order to count the number of records, you can get that from $collection->toArray().

The loader can extract MARC records from any container XML, so you can pass in an SRU or OAI-PMH response directly:

If you only have a single record, you can also use Record::fromFile, Record::fromString or Record::fromSimpleXMLElement. These use the Collection methods under the hood, but returns a single Record object.

Editing records

Records can be edited using the editing capabilities of File_MARC (API docs). See an example to get started.

Querying with MARCspec

Use the Record::query() method to query a record using the MARCspec language as implemented in the php-marc-spec package package. The method returns a QueryResult object, which is a small wrapper around File_MARC_Reference.

Example: To loop over all 650 fields having $2 noubomn:

or we could reference the subfield directly, like so:

You can retrieve single results using first(), which returns the first match, or null if no matches were found:

In the same way, text() returns the data content of the first match, or null if no matches were found:

Convenience methods on the Record class

The Record class extends File_MARC_Record with a few convenience methods to get data from commonly used fields. Each of these methods, except getType(), returns an object or an array of objects of one of the field classes (located in src/Fields). For instance getIsbns() returns an array of Scriptotek\Marc\Isbn objects. All the field classes implements at minimum a __toString() method so you easily can get a string representation of the field for presentation purpose.

Note that all the get methods can also be accessed as attributes thanks to a little PHP magic (__get). So instead of calling $record->getId(), you can use the shorthand variant $record->id.

type

$record->getType() or $record->type returns either 'Bibliographic', 'Authority' or 'Holdings' based on the value of the sixth character in the leader. See Marc21.php for supporting constants.

catalogingForm

$record->getCatalogingForm() or $record->catalogingForm returns the value of LDR/18. See Marc21.php for supporting constants.

id

$record->getId() or $record->id returns the record id from 001 control field.

isbns

$record->getIsbns() or $record->isbns returns an array of Isbn objects from 020 fields.

title

$record->getTitle() or $record->title returns a Title objects from 245 field, or null if no such field is present.

Beware that the default string representation may or may not fit your needs. It's currently a concatenation of $a (title), $b (remainder of title), $n(part number) and $p (part title). For the remaining subfields like $f, $g and $k, I haven't decided whether to handle them or not.

Parallel titles are unfortunately encoded in such a way that there's no way I'm aware of to identify them in a secure manner, meaning there's also no secure way to remove them if you don't want to include them.1

I'm trimming off any final '/' ISBD marker. I would have loved to be able to also trim off final dots, but that's not trivial for the same reason identifying parallel titles is not2 Since explicit ISBD markers are included in records catalogued in the American tradition, but not in records catalogued in the British tradition, a mix of records from both traditions will look silly.

subjects

$record->getSubjects($vocabulary, $tag) or $record->subjects returns an array of Subject and UncontrolledSubject objects from all the 6XX fields. The getSubjects() method have two optional arguments you can use to limit by vocabulary and/or tag.

Static options:

Notes

It's unfortunately easy to err when trying to present data from MARC records in end user applications. A developer learning by example might for instance assume that 300 $a is a subfield for "number of pages".3 A quick glance at e.g. LC's MARC documentation would be enough to prove that wrong, but in other cases it's harder to avoid making false assumptions without deep familiarity with cataloguing rules and practices.

1 That might change in the future. But even if I decide to remove parallel titles, I'm not really sure how to do it in a safe way. Parallel titles are identified by a leading = ISBD marker. If the marker is at the end of subfield $a, we can be certain it's an ISBD marker, but since the $a and $c subfields are not repeatable, multiple titles are just added to the $c subfield. So if we encounter an = sign in the middle middle of $c somewhere, how can we tell if it's an ISBD marker or just an equal sign part of the title (like in the fictive book "$aEating the right way : The 2 + 2 = 5 diet")? Some kind of escaping would have made that clear, but the ISBD principles doesn't seem to call for that, leaving us completely in the dark. That is seriously annoying :weary: ↩

2 According to ISBD principles "field 245 ends with a period, even when another mark of punctuation is present, unless the last word in the field is an abbreviation, initial/letter, or data that ends with final punctuation." Determining if something is "an abbreviation, initial/letter, or data that ends with final punctuation" is certainly not an easy task for anything but humans and AI. ↩

3 Our old OPAC used to output something like "Number of pages: One video disc (DVD)…" for DVDs – the developers had apparently just assumed that the content of 300 $a could be represented as "number of pages" in all cases. While that sounds silly, getting the number of pages (for documents that actually have pages) from MARC records can be ridiculously hard; you can safely extract the number from strings like 149 p. (English), 149 s. (Norwegian), etc., but you must ignore the numbers in strings like 10 boxes, 11 v. (volumes) etc. So for a start you need a list of valid abbreviations for "pages" in all relevant languages. Then there's the more complicated cases like 1 score (16 p.) – at first sight it looks like we can tokenize that into (number, unit) pairs, like ("1 score", "16 p.") and only accept the item(s) having an allowed unit (like p.). But then suddenly comes a case like "74 p. of ill., 15 p.", which we would turn into ("74 p. of ill.", "15 p."), accepting 15 p., not the correct 74 p.. So we bite into the grass and start writing rules; if a valid match is found as the start of the string, then accept it, else if …, else try tokenization, etc... it quickly becomes messy and it will certainly fail in some cases. Sad to say, after a few years in the library, I still haven't figured out a general way to extract the number of pages a document have using library data. ↩


All versions of marc with dependencies

PHP Build Version
Package Version
Requires php Version >=8.0
ext-xml Version *
ext-json Version *
ext-simplexml Version *
ck/file_marc_reference Version ^1.2
pear/file_marc Version @dev
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package scriptotek/marc contains the following files

Loading the files please wait ....