See also #249 on the vagueness of http://schema.org/contentLocation

I had read this as the place where the Thing is. For example, my local library may be the contentLocation of a copy of Macbeth. Am I reading that wrong? If so, we can just tighten the definition.

@vholland your guess is as good as anyone's here re contentLocation. The ancients have not left us adequate records of their initial vision here, unfortunately. From an unscientifically anecdotal look at a few pages that use it, country seem to be amongst common values for the property. But that makes a kind of sense even if to mean "where is the copy now", in that the bigger a place is always going to have more items associated to it than a smaller place (UK versus Dan's Desk).

I'm curious if @dbs is seeing any particular interpretation of this property for holdings data in library systems - https://coffeecode.net/archives/271-RDFa-and-schema.org-all-the-library-things.html doesn't mention it explicitly. Dan, any thoughts?

We already have a "recordedAt" property for CreativeWork which would seem to fulfil the requirement for where the CreativeWork depicts (currently "recordedAt" expects schema.org/Event, but I'd suggest that schema.org/Place be added as well).

So what's missing is a property to specify where an instance of CreativeWork resides - of course that would only be of use where the CreativeWork is a unique object (e.g. a piece of VisualArtwork). contentLocation would fit that bill, but I can imagine people easily getting confused between recordedAt and contentLocation.

Edit to add:

I'd be tempted to add 3 properties:

• locationCreated - expects Event or Place - where the CreativeWork was created
• locationRecorded - expects Event or Place (replaces "recordedAt") - where the CreativeWork depicts/records
• locationResides - expects Place, URL, Thing (replaces "contentLocation") - where the instance of the CreativeWork can currently be found

The benefit of having them all start with "location" is that it makes it easy for developers/publishers to compare them when looking at the schema.org/CreativeWork documentation (because peoperties are listed in alphabetical order in the documentation)

Example 1: da Vinci's Mona Lisa

• locationCreated - da Vinci's studio
• locationRecorded - Italian mountains
• locationResides - Louvre, Paris

Example 2: video of Glastonbury Festival, 2013

• locationCreated - Glastonbury (Place)
• locationRecorded - Glastonbury Festival, 2013 (Event)
• locationResides - http://youtube.com/example-url (URL) - or Thing (embedded video object)

I've been looking at uses of contentLocation and authors use it for either the location of the item or where the item was created, depending on the author's needs and interpretation of the vague description.

My only concern with using "locationRecorded" is people are already using "recordedAt" for the same idea. I hate to break their markup without a compelling reason.

There is metaphysics involved here-
A "creative work" does not necessarily reside anywhere.

There are certain stances you can take that would allow you to assign a
spatial region to the creative work "Moby Dick", which would be the same as
the space occupied by every single copy of the work (including copies in
people's heads). Every time a copy was moved, this region would change.
This is rarely useful unless required by other commitments.
Even less generally useful is to have the spatial region assigned to such
an abstract object be the entire universe.
These stances are sometimes necessary when working within certain
frameworks, but sdo does not have such commitments.

The alternate reading, which would describe the region that the creative
work is "about". This is much more generally useful, since sdo already
commits to abstract objects and at least an intentional stance.

For LCSH practice cf "Ireland--in motion pictures", "Ireland--Motion
pictures", and "Motion pictures, Irish".

For treatment of unique instances of creative works see FRBRoo and the
CIDOC CRM on which it is based. Museum people deal with a lot of creative
works with only a single copy, so this is something they pay attention to.
:-)
On Feb 6, 2015 11:13 AM, "Dan Brickley" notifications@github.com wrote:

@vholland https://github.com/vholland your guess is as good as anyone's
here re contentLocation. The ancients have not left us adequate records of
their initial vision here, unfortunately. From an unscientifically
anecdotal look at a few pages that use it, country seem to be amongst
common values for the property. But that makes a kind of sense even if to
mean "where is the copy now", in that the bigger a place is always going to
have more items associated to it than a smaller place (UK versus Dan's
Desk).

I'm curious if @dbs https://github.com/dbs is seeing any particular
interpretation of this property for holdings data in library systems -
https://coffeecode.net/archives/271-RDFa-and-schema.org-all-the-library-things.html
doesn't mention it explicitly. Dan, any thoughts?

—
Reply to this email directly or view it on GitHub
#323 (comment).

Running through schemabibex archives, all of the references I found to contentLocation seemed to assume that it referred to the physical location of the described work itself (the physical book, the sculpture, etc), not the about-ness of the work (which schema:about seems to capture much more nicely).

• https://lists.w3.org/Archives/Public/public-schemabibex/2013Oct/0003.html
• https://lists.w3.org/Archives/Public/public-schemabibex/2013Feb/0067.html
• https://lists.w3.org/Archives/Public/public-schemabibex/2014Feb/0039.html

That said, we largely focused on the Product/Offer schema to locate individual instances of a work.

@sesuncedu This is where schema.org's simplicity of describing all levels of FRBR as "CreativeWork" makes things messy. I can describe Moby Dick at the Work, Expression, Manifestation, or Item level and still use schema.org/Book.

Based on the analysis from @dbs above, there is some momentum for using contentLocation to describe the physical item's location (which was my reading of the property).

The simplest thing may be to:

1. Clarify the description of contentLocation to state it is the physical location of an item.
2. Extend the range for recordedAt to be a Place.

Pretty sick right now so my brain is not working well, but my analysis only showed that the knee-jerk interpretation of contentLocation in schemabibex was that it was the physical item's location; however, due in no small part to the challenges @sesuncedu raised, we opted not to map anything to that property in any of our recommendations, preferring the much more concrete Offer with its useful time-dimension availabilityStarts / availabilityEnds / validFrom / validThrough properties.

In the land of sculptures and paintings for example, I would be tempted to use Event or VisualArtsEvent's workPerformed property to situate the availability of a given item at a point in time and space.

However, for those items which exist but for which there is no associated offer to view or purchase (for example, a sculpture in a private collection), perhaps contentLocation would be the property of last resort. (Can we say that in the description?)

Part of me (probably the suffering-from-a-fever part) wishes that it could be a compound property or type, say, hasTARDIS (for "has time and relative dimension in space") that recorded both the time + the location (and probably an optional description for annotation purposes); that way an item that has moved could, in an open world context, have multiple hasTARDIS assertions associated with it tracking it in time and space.

Oh, and @vholland for more fun you could use schema:Book at the Work, Expression, Manifestation, and Item levels connecting them via exampleOfWork or workExample, and then hang other Expressions off of the work (e.g. Moby Dick the film adaptation, the comic book, the musical, etc). Which could potentially actually be useful from a research context.

What this suggests to me is that, outside of the Event & Offer types which have significant limitations, we don't really have a good way of describing concrete instances of entities.

tl;dr: I recommend making contentLocation a sub-property of "about" and clarifying the definition. We can then either add new types or properties for physical location.

My reasoning:
I've been digging through the usage data I could find. There are 3 cases:

1. The most common case is purely virtual CreativeWorks. Blog, BlogPosting, Article, and ImageObject are the most common uses of this property. In those cases, contentLocation references a location the work is about. Oddly, authors who use Photograph fall into this category even though Photograph is more like category 3 below.
2. The less common case is largely physical CreativeWorks. The notable type here is Sculpture. In this case, authors use contentLocation for the location where they physical item is held. Authors who use Painting also tend to interpret contentLocation this way, even if Painting is more like category 3.
3. The least common case is for CreativeWorks which may be interpreted as a physical or virtual thing. Book falls in this category. A book sitting on my shelf in Cambridge about touring Paris seems equally likely to have a contentLocation of Cambridge as Paris.

Given the usage patterns, it seems best to clarify the definition of contentLocation to be what the work is about. We should also make it subproperty of the "about" property.

The bibextend group has already been using Product and Offer to describe the physical item. I know there is another discussion (around cars?) about allowing things other than Products to have physical dimensions and weight. If we went down that path, we could add location to the list.

@vholland uhmm, where's category 3 ?

How odd. Github didn't like my Markdown and re-numbered 3 as 1. Should be fixed now.

I used example of a Book in discussion around issue with defining Tangible things as subclass of Product: #404 (comment)

Product also shows one of the possible patterns to distinguish a book from particular physical copy of a book

• http://schema.org/Product
• http://schema.org/IndividualProduct

http://schema.org/location looks like generic property to reference physical locations

It might also make sense to define createdAt and make recordedAt subclass of it.

Note that in the case of a book, even the abstract creative works can be offered and as such be a product.

If I sell all rights on a certain composition to someone, then the promise to transfer rights on this "thing" means the creative works, not its manifestations. Even ideas, dreams, or world peace can be objects in the sense of schema:Product.

So I would not use schema:Product as a general pattern to distinguish an abstract creative works from its physical representations. Even schema:ProductModel would for me typically be a particular edition of a works (a book title), not its abstract ideal (the works in itself).

So I would not use schema:Product as a general pattern to distinguish an abstract creative works from its physical representations. Even schema:ProductModel would for me typically be a particular edition of a works (a book title), not its abstract ideal (the works in itself).

+1

The conceptual work would just be a CreativeWork or subtype

The edition (expression or manifestation in library terms) would be both a CreativeWork and ProductModel. The single copy on a shelf being a CreativeWork and IndividualProduct.

~Richard.

I think we should postpone this for sdo-gozer. (when we come back to this, we should review what @lazaruscorporation has drafted up as further needs and definition clarification.

Happy to pospone.

When revisiting this — CreativeWork for conceptual work, and CreativeWork + Product type/subtype for representing physical examples of a work — we should reference to the extended discussions that occurred on this subject in the Schema Bib Extend Group.

The library community, which has been obsessing about the relationships between Works, Expressions, Manifestations, and Items for many years, have many representative on the SchemaBibEx group. We looked at this in depth and how these relationships and structures could be represented in Schema without replicating the rigid structures applied in the library world using the FRBRhttp://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records model.

The conclusion was that this combination of CreativeWork & subtypes plus Product & subtypes was an effective solution. To help visualise things we used an example library with examples representations and their approximations to their FRBR equivalents. This can be found on the SchemaBibEx wiki: https://www.w3.org/community/schemabibex/wiki/Examples/mylib

~Richard

On 22 Apr 2015, at 00:11, Thad Guidry <notifications@github.commailto:notifications@github.com> wrote:

I think we should postpone this for sdo-gozer. (when we come back to this, we should review what @lazaruscorporationhttps://github.com/lazaruscorporation has drafted up as further needs and definition clarification.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/323#issuecomment-94968547.

I created pull request #449 to clarify the definition of contentLocation.

I am happy to wait until after sdo-gozer to determine how to handle physical locations.

Would suggest a minor extra tweak to the description to broaden its understanding:

The location depicted or described in the content. For example, the location in a photograph or painting.

~Richard

On 23 Apr 2015, at 21:10, vholland <notifications@github.commailto:notifications@github.com> wrote:

I created pull request #449#449 to clarify the definition of contentLocation.

I am happy to wait until after sdo-gozer to determine how to handle physical locations.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/323#issuecomment-95705830.

@Dataliberate Good idea. Done.

Sounds like rough consensus. @vholland shall we now mark this current issue for Q2 milestone?

I moved it to Q2.

In trying to complete this, what do people think of adding locationCreated. See pull request #624.

+1 for locationCreated.

I would probably only use it for images however... other kinds of CreativeWorks it just doesn't seem that useful or interesting a property to me, anyways... "show me all the poems or songs created in Denver, Colorado"... boring, who cares..but I bet someone in this world does.

+1 here too. While indeed "poems written in Denver" might not be the most useful bit of data one could envision, I don't think its too difficult to come up with more compelling use cases.

At first blush, chief among these is stating the filming location for Movie, Episode and TVSeries. Right now one can say that a contentLocation - a "location depicted or described in the content" - for Game of Thrones is "Winterfell", but no way to say that it was filmed in County Down, Northern Ireland.

This is important enough to IMDb that they have a sub-page dedicated to filming locations (e.g.).

+1

~Richard

On 27 Jun 2015, at 03:23, Aaron Bradley <notifications@github.commailto:notifications@github.com> wrote:

+1 here too. While indeed "poems written in Denver" might not be the most useful bit of data one could envision, I don't think its too difficult to come up with more compelling use cases.

At first blush, chief among these is stating the filming location for Movie, Episode and TVSeries. Right now one can say that a contentLocation - a "location depicted or described in the content" - for Game of Thrones is "Winterfell", but no way to say that it was filmed in County Down, Northern Ireland.

This is important enough to IMDb that they have a sub-page dedicated to filming locations (e.g.http://www.imdb.com/title/tt0034583/locations).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/323#issuecomment-115785624.

WfM

Ok, re-reading this I think this goes in. Thanks all!

+1

Please review: http://sdo-phobos.appspot.com/locationCreated

( part of pending release, see: http://sdo-phobos.appspot.com/docs/releases.html )

Fixed in http://schema.org/docs/releases.html#v2.2 - thanks all