Linked Art / Schema.org mapping?

azaroth42 commented 1 year ago

At Yale we would benefit from a mapping from linked art into schema.org to generate and embed into our LUX entity pages.

e.g. if we could transform the incoming linked art into HTML and schema.org's json-ld to be embedded within the page, when google crawls it (or other systems), the schema.org structured data would make that indexing much stronger.

This seems like a useful result for the community, not just Yale, and something we could collaborate on?

edwardanderson commented 1 year ago

Definitely yes! We're mapping our internal Bibframe representations of library resources out to schema.org already and have ambitions to do the same for Linked Art in the future.

azaroth42 commented 1 year ago

Some basic mappings to get the ball rolling:

Baseline

/identified_by[type=Name][classified_as/id=PRIMARY_NAME]/content --> /name
/identified_by[type=Name]/content --> /alternateName
/identified_by[type=Identifier]/content --> /identifier
/equivalent/id --> /sameAs
/id --> /url
/referred_to_by[classified_as/id=DESCRIPTION]/content --> /description
/representation/digitally_shown_by/access_point/id --> /image
/subject_of/digitally_carried_by/access_point/id --> /mainEntityOfPage
/classified_as/id --> /additionalType

Person

/born/timespan/begin_of_the_begin --> /birthDate
/born/took_place_at/id --> /birthPlace
/died/timespan/begin_of_the_begin --> /deathDate
/died/took_place_at/id --> /deathPlace
/contact_point[classified_as=EMAIL]/content --> /email
/classified_as[classified_as=GENDER]/id --> /gender
/classified_as[classified_as=OCCUPATION]/id --> /hasOccupation
/residence/id --> /homeLocation
/member_of --> /memberOf
/classified_as[classified_as=NATIONALITY]/id --> /nationality

Group

/contact_point[classified_as=ADDRESS]/content --> /address
/dissolved_by/timespan/begin_of_the_begin --> /dissolutionDate
/formed_by/timespan/begin_of_the_begin --> /foundingDate
/formed_by/took_place_at/id --> /foundingLocation
/formed_by/carried_out_by/id --> /founder
/residence/id --> /location
/member_of --> /memberOf
(If a particular image is known to be a logo, rather than some other representation, use /logo not /image)
/member_of --> /parentOrganization (if known to be hierarchical, rather than some other membership)

Place

/part_of/id --> /containedInPlace
/defined_by --> /geo ; or /latitude and /longitude if a point
(If a particular image is known to be a map, use /hasMap not /image)

Type / Language / Material / Currency

I can't find a good mapping beyond Thing. There is a Language class, but it has no features beyond those of Thing. There's also Intangible ... but also no properties beyond Thing.

edwardanderson commented 1 year ago

Type might map on to schema:DefinedTerm?
~Currency to schema:StructuredValue?~

azaroth42 commented 1 year ago

DefinedTerm -- I was looking for a way to have a broader or narrower relationship, which I can't see anywhere. Agree that it's probably the closest. inDefinedTermSet is useful (the equivalent of skos:inScheme) but no other Type related notions.

There's a closer fit in terms of properties: https://schema.org/Taxon but not definition as it's explicitly about biological classification.

edwardanderson commented 1 year ago

Is skos:narrower somewhat aligned with schema:greater? Although maybe schema:QualitativeValue is too much of a reach?

azaroth42 commented 1 year ago

I think greater is more for the relationship between siblings -- the concept of "impossible" is somehow greater than the concept of "easy", but both are narrower than "difficulty"

What about CreativeWork and isPartOf ?

edwardanderson commented 1 year ago

Not mapping questions but...

Would we imagine incorporating the schema.org response into the Linked Art API with something like profile selection/negotiation? Or are we thinking more along the lines of making a library for supporting the transformation for unspecified implementations?
Do we have a preference for a particular flavour of serialisation?
- JSON-LD -[XSLT/?]-> JSON-LD
- RDF (any) -[SPARQL CONSTRUCT]-> RDF (any)
- JSON-LD (?) -[?]-> Microdata etc. etc.

edwardanderson commented 1 year ago

RE: schema:isPartOf. This works. Class definition might be a bit of a reach.

Could we use AAT page URLs for Types and then use schema:WebPage and schema:relatedLink and just flatten (!) all the hierarchies? Seems bad and lossy and also weird.

aisaac commented 1 year ago

Yes schema:greater is no match for the SKOS relationships. And schema:DefinedTerm is the best match for skos:Concept But maybe we shouldn't devote a lot of time on types/concept to begin with. I'm not sure it's straightforward in Schema.org, as some "types" have made their way to Schema.org as items in instances of schema:Enumeration (https://schema.org/Enumeration) and these instances don't seem to be related to schema:DefinedTerm

bulbil commented 1 year ago

A little late to the conversation, but I wanted to mention that we have a workflow that maps linked art to schema.org in (a roundabout way) at the Getty, both in our museum collection pages and archival research collections. But we would love a less ambiguous mapping! We would be most interested in JSON-LD -> JSON-LD mapping.

We index some fields from our linked art LOD to an ElasticSearch index then generate schema.org json from those indexed documents -- below is cribbed from our implementation of Schema.org's Python helpers.

We use the following schema types:

       [
            "CreativeWork",
            "Photograph",
            "Sculpture",
            "Drawing",
            "Painting",
            "Manuscript",
            "Book",
            "Person",
            "Organization",
            "Place"
        ]

Here's some relevant parts of the code, though much of this repeats what has already been discussed above.

    ## add the recipe for validation
    schema.add_property("name", result["primary_name"])
    add_schema_field(schema, "description", "description", result)

    ## person login
    add_schema_field(schema, "birth_place", "birthPlace", result)
    add_schema_field(schema, "born", "birthDate", result)
    add_schema_field(schema, "death_place", "deathPlace", result)
    add_schema_field(schema, "died", "deathDate", result)

    if "accession_number" in result:
        identifiers.append(result["accession_number"])
    if "manuscript_number" in result:
        identifiers.append(result["manuscript_number"])
    if "object_number" in result:
        identifiers.append(result["object_number"])
    identifiers = list(set(identifiers))
    schema.add_property("identifier", identifiers)

    add_schema_field(schema, "materials", "material", result)
    add_schema_field(schema, "rights_statement_id", "license", result)
    add_schema_field(schema, "dimensions", "size", result)
    add_schema_field(schema, "alternate_titles", "alternate_name", result)

    place.add_property("name", result["place_created"])
    schema.add_property("locationCreated", place)
    schema.add_property("thumbnailUrl", result["manifest"]["thumb"])
    schema.add_property("creditText", credit)

    schema.add_property("creator", producers)
    add_schema_field(schema, "date_created", "temporal", result)

edwardanderson commented 1 year ago

Just checked our alpha BIBFRAME to Schema.org transformation and we're using:

<> a schema:DefinedTerm ;
  schema:hasPart <> ;
  schema:isPartOf <> ;
  schema:sameAs <> ;
  schema:name "" .

azaroth42 commented 1 year ago

And just ignore the "expected" domain and range of hasPart / isPartOf? They expect CreativeWork, but DefinedTerm is an Intangible. That's probably the best we can do, beyond asking for another property to be added to schema.

edwardanderson commented 1 year ago

Looks like we should refactor our implementation a little. Also logging here that the Schema.org initiative have twice decided against extending the domain of hasPart and isPartOf:

azaroth42 commented 11 months ago

Should be able to round-trip data back to linked art, or understand where there are challenges.

edwardanderson commented 11 months ago

A little bit more noodling on the Concept hierarchy problem.

And just ignore the "expected" domain and range of hasPart / isPartOf?

Can we (ab)use composite classes so that broad Concept instances are both schema:DefinedTerm and schema:DefinedTermSet? And then extend the schema:inDefinedTermSet property with a schema:additionalType SKOS qualification?

<http://vocab.getty.edu/aat/300033618>
    a schema:DefinedTerm ;
    schema:name "Painting" ;
    schema:inDefinedTermSet <http://vocab.getty.edu/aat/300133025> .

<http://vocab.getty.edu/aat/300133025>
    a schema:DefinedTerm, schema:DefinedTermSet ;
    schema:name "Work of Art" .

schema:inDefinedTermSet
    schema:additionalType "http://www.w3.org/2004/02/skos/core#narrower"^^schema:URL .

Actually schema:inDefinedTermSet is a subclass of schema:isPartOf... so maybe we don't need the SKOS relation?

azaroth42 commented 9 months ago

What about ...

<http://vocab.getty.edu/aat/300033618>
    a schema:DefinedTerm, schema:CreativeWork ;
    schema:name "Painting" ;
    schema:inDefinedTermSet <http://vocab.getty.edu/aat/> ;
    schema:isPartOf <http://vocab.getty.edu/aat/300123456> .

azaroth42 commented 9 months ago

Object Strawperson

Baseline plus...

/type --> VisualArtwork, ArchiveComponent
/classified_as/id --> /artform (painting, sculpture, etc)
/referred_to_by[classified_as/id=DESCRIPTION]/content --> /abstract (other classes use /description)
/referred_to_by[classified_as/id=RIGHTS_STMT]/content --> /copyrightNotice
/referred_to_by[classified_as/id=ACCESS_STMT]/content --> /conditionsOfAccess
/referred_to_by[classified_as/id=CREDIT_STMT]/content --> /creditText
/referred_to_by[classified_as/id=MATERIAL_STMT]/content --> /artMedium
/produced_by/part*/carried_out_by --> /creator or /artist
/produced_by/part*[classified_as=CONTRIBUTOR]/carried_out_by --> /contributor
/produced_by/took_place_at (if a country) --> /countryOfOrigin
/produced_by/timespan --> /dateCreated
/produced_by/took_place_at --> /locationCreated
/partOf --> /isPartOf
/shows|carries --> /exampleOfWork
/made_of --> /material
/content --> /text
/dimension[classified_as/id=HEIGHT]/value --> /height
/dimension[classified_as/id=WIDTH]/value --> /width
/dimension[classified_as/id=DEPTH]/value --> /depth
/current_owner --> /holdingArchive
/current_location --> /itemLocation

Missing:

destruction, partRemoval -- no way to model this in schema that I can find

azaroth42 commented 9 months ago

Work Strawperson

Baseline plus ... /type = CreativeWork (for both Visual and Linguistic)

/about --> /about
/represents[./type=Place] --> /contentLocation
/represents (for all) --> /mainEntity
/language --> /inLanguage (to the Language concept)
/classified_as (where the Concept is a genre) --> /genre
/created_by/part*/carried_out_by --> /author, /artist, or /creator
/used_for[./classified_as/id=PUBLISHING]/carried_out_by --> /publisher
/content --> /text
/dimension --> /size
/format --> /encodingFormat

azaroth42 commented 9 months ago

Digital Object Strawperson

/type = CreativeWork, DataSet

/digitally_shows|digitally_carries --> /exampleOfWork
/dimension[classified_as/id=HEIGHT]/value --> /height
/dimension[classified_as/id=WIDTH]/value --> /width
/dimension[classified_as/id=DEPTH]/value --> /depth
/dimension --> /size
/part_of --> /isPartOf
/format --> /encodingFormat
/conforms_to --> ??
/access_point --> /distribution
/created_by/part*/carried_out_by --> /creator
/used_for[./classified_as/id=PUBLISHING]/carried_out_by --> /publisher

azaroth42 commented 9 months ago

Collated the mappings as they stand here: https://deploy-preview-540--linked-art.netlify.app/cookbook/mappings/schema.org/

azaroth42 commented 8 months ago

Noting from discussion with @krpage and @workergnome (and others) that the Schema.Org representation needs to link to the Linked Art representation (and isn't explicit in the above mapping)

LvanWissen commented 2 months ago

Is the mapping ready to be deployed to https://linked.art/cookbook/mappings/schema/ ?

linked-art / linked.art