Example question. Note the "question" tag.

And we are more specific about the nature of the digital thing, that it is a web page.

And we're done!

Web pages are digital things that exist in computers.

The URI of the web page.

The inverse of "about", this book is the subject of another entity ... in this case a web page about the book, generated by the library catalog.

This property lists other identities for the referencing entity. In this case Indonesia is also known as lc's country "io", allowing us to connect to external datasets.

The class for Places, which are geographical spaces, not necessarily countries or other geopolitical entities.

This property refers to a Place or location where the activity took place. In this case it happened in Indonesia.

This is the earliest possible time that the activity could have begun taking place. It is normally paired with end_of_the_end being the latest possible time when the activity would have stopped taking place (but that was not provided in the input record)

Again, we have a label that can be displayed to represent the TimeSpan to end users, as supplied by the content publisher. Without this Name, the application would need to derive it from the begin and end timestamps, which are intended more to drive search.

This property references a TimeSpan, which holds the begin and end timestamps, duration, and other details about the time at which the activity took place.

We use the classified_as pattern to be more specific about the sort of Activity we're describing, in this case it is publishing.

Activity is the general class of all things which are intentionally performed by people or groups. Creation and AttributeAssignment are subclasses of it.

There isn't a specific "publication" activity, so instead we use "used_for" to refer to an Activity, which is then classified_as Publishing. There might be other activities in used_for as well as publications, such as performances of music or theatrical works.

The carried out by field references the actor (person or group) that carried out the activity. In this case it is a Person (compare to the Group that carried out the attribute assignment above) with a given Name.

The classification of the part of the activity gives the role that the actor played in the creation. In this case it is flagged as "creator"

In this case there is only one author, and thus only one part. We leave it in for consistency with other texts that have multiple authors.

This field references the Creation event of the text -- the authorship, separate from the publication and distribution of carriers (the physical books) of the work. There can only be one creation event, and so to ensure that multiple authors can have different roles (author vs editor vs book-plate designer), each author has a separate 'part' of the overall Creation activity.

We classify the set as a curated collection, to distinguish from other Sets.

Sets are not part of the core CIDOC-CRM ontology. Only collections of physical objects are handled in CRM. This Set class comes from the Linked Art extension, and is a set of any class of entity including multiple classes in the same set ... important as texts, physical things, and other sets (e.g. archival collections) can be collected together.

This field lists the sets or collections which the entity is a member of. In particular, these are the collections of the different units.

Here we have an Identifier for the language. In this case a 3 letter code. These codes should also have additional classifications to be able to distinguish glottolog codes from 2 letter from 3 letter and so on, just like the identifiers of the main entity. Languages can also have Names and the other common properties.

The type for languages is Language, helpfully.

This field gives the languages in which the content of the text is written. In this case it has three languages: Madurese, Malay and Arabic.

Again, we have a meta-type ... the type of this concept is "Form".

This field lists the "influences" on the main type. Pre-coordinated terms are not necessarily narrower than their influences, as the influence might not be a classification. For example History -- France -- 14th Century has a Place and a Period as influence, and it would not be correct to have a Concept being narrower than a Place.

Type here is a Concept -- the concept of Adaptions of Arabic fables, as given in the Name. The divisions (facets) of the subject are described below.

Here we have another text, which this text is about. It uses the same LinguisticObject class as both statements and the book's textual content.

This field lists the entities which the text is about, or has as subjects. In this case, it is about another text called "Kalilah wa-Dimnah", and has the concept "Fables, Arabic--Adaptions" as subject. This is a good example of the text being about more than just concepts, they can be about anything (people, places, objects, texts, images, concepts, etc.) which is more descriptive than just a "subject" field

This Name, classified as a 'Display Title', is the label to use for the statement, rather than a system-generated default based on the classification. It thus allows UI details to come from the content provider, rather than the viewing application.

Like everything else, statements are classified in order to be more specific about what sort of text it is. There are likely to be many such statements in a particular record.

This classification (brief text) is of a higher level classification (production statement). This allows systems to recognize statements broadly speaking, without necessarily having a comprehensive list of all of the classifications that might be applied. This is called a "meta type" as it is a "type of a type". aat:300418049 will be consistent across all Linked Art implementations for this purpose.

As a (short) text, the statement has the same class as the main book. It is textual content, that can refer to other entities, is written by someone, in a particular language, and so forth. The only difference is that this is short enough to be embedded in its entirety within the JSON.

The referred_to_by property contains the notes, descriptions, statements, notes, and other texts that refer to or are somehow about this book. Each statement will have a classification for what sort of statement it is, and content for the actual statement, in the same way as Names and Identifiers do.

This is the URI for the object, from which the description can be retrieved as JSON. It is used when other entities want to refer to this one, such as if there was a book review of this book, it would be about this entity and use this URI to uniquely identify it.

Groups are sets of people that can be said to carry out activities. Clearly it was an individual within the group that actually assigned this identifier, rather than every member of the group. Groups and People would benefit from further descriptions as unique entities themselves.

The assigned_by property allows us to refer to the activity (an Attribute Assignment) whereby the identifier was assigned to the book. In this case the Identifier is a call number, and multiple groups within the university can assign different call numbers to the same text for their own copies. This reference to the Library means that the PL5354 call number is the Library's call number, whereas if YPM also had a copy, it would likely have a different call number with the same classification, but assigned by a different Group.

Note that this classification as an OCLC number is repeated for the next Identifier as well. The UUID is the key that ensures that both can be treated the same way, regardless of where they are encountered. Repeating classifications like this is to be expected.

This entry in the list is the first Identifier, but follows the same structure as Names. They are classified with the particular type of identifier, in this case an LCCN, and have a content field with the value of the identifier.

This Name has the exact same content as the previous, but a different role -- it is the name to use to sort the record by its title.

Names are titles or textual labels for things. This class distinguishes this entry in the list from the Identifiers, below.

Note that the Name does NOT have an id field. This makes it a "blank node" that can only be referred to within this particular record, and not from other records. Instead external references would need to be to the book itself. (This could be changed if a use case with data arises for referring to names directly)

This is the actual string content of the Name that could be displayed to a user as a title.

Names (and indeed everything) can also be classified to provide the role that the name is taking, relative to the entity. This is the Primary name of the book, or the main title, for which we use aat:300404670 to distinguish from other sorts of Name.

The book has two different types of identifier in the identified_by property -- Names (which are language based) and Identifiers (which are not). Names are said to identify the object because they are unique as entities to the object, even if they contain the same string value (in content) as another Name.

Like the use of id above, this is the URI of the classification. In this case it is the AAT term for books. The term also has a class (Type, or you can read it as Concept), and a label, just like the main entity.

This field holds all of the classifications of the resource, both super types and specific types. It can also have other classifications beyond type, including style or genre.

This label is just for internal documentation, so that when the resource is displayed, systems can pick the _label up and use it without needing to worry about different languages, document structures and so forth. It's always a single string, and can be whatever is useful. It should NOT be displayed directly to end users however, that's what the Name structure is for.

This is the class of the main resource, a Linguistic Object or, less arcanely, a Text.

This is the JSON-LD context document from Linked Art. It can be used to process the JSON into Linked Data, but otherwise can be completely ignored.

This is the first example

This is the context ... bla bla bla

This is the JSON-LD context. It allows the rest of the JSON document to be interpreted as Linked Open Data, and otherwise can be ignored.

This is the context, it lets code interpret the JSON document as Linked Data, and otherwise can be ignored completely.

"Mrs Vincenzo Ardenghi" is actually "Anna Heaton Fitch Farnham" from the provenance, widow of William Farnham, the treasurer of Yale.

Suggest: The Working Group will initially be divided into two Task Forces to organize the work, with a Data Task Force focusing on the model (#1), and a Client Task Force focusing on requirements for a Client-side API (#5). As work progresses and the overlaps between the Task Forces become greater, the structure and priorities are likely to change.

(new) second target for e-book comment

I see the "may" but not sure that the features are algorithmic? My understanding of 4 is that there will be a defined processing model for how to use the information conveyed in an annotation to select the region of interest. The input to that processing model may come from (...) but the /algorithm/ isn't expressed as those things?

I'm not sure how 3 and 6 can be split apart. If the API says "we return JSON-LD" and the serialization side says "we don't use JSON-LD, just this homegrown solution" ... then there's a huge mismatch. Yes this is overblown, but I'm dubious about that particular split.

Interesting. The algorithm should be worked on early, as it will need to inform any required changes to the data model (eg, new selectors)

... to create, access and manage annotations ... Otherwise it's just HTTP GET.

environments, or an environment. Given further use later, I prefer: an annotation ecosystem

e-book or ebook ? [internal note: multiple targets please to link to other occurences!]