New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

preferredness, notability, or importance #1726

Open
VladimirAlexiev opened this Issue Aug 24, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@VladimirAlexiev

VladimirAlexiev commented Aug 24, 2017

I think there's need for a general mechanism to indicate preferredness, notability, or importance. Examples:

  • FAQPage (as opposed to QAPage), see #1723
  • cultural heritage, where it's important to indicate the preferred image (eg overall recto, not verso or detail) and title of an artwork
  • Getty TGN Comment Flag "Famous / Noted" (eg set for Paris, France but not Paris, Texas)

Should we just use additionalType with a fixed value? Where should this be documented?

@nicolastorzec

This comment has been minimized.

Contributor

nicolastorzec commented Aug 24, 2017

I'm not sure about using additionalType for this. It was designed for a different purpose.

Thoughts below.

Re: canonical name vs alternate names:
We can already use properties like name and alternateName. I agree that they don't capture contexts and preferences though: e.g. here is the preferred name for context A and here is the preferred name for context B; or here is the most notable name and here is the 3rd most notable name.

Re: hero image vs other images:
We can use a property like image on any Thing, as well a property like primaryImageOfPage on a WebPage. We could generalize primaryImageOfPage and add something like primaryImageOfEntity. Similarly to name vs. alternateName it would cover simple needs but would not capture preferences and contexts.

Re: ordering in general:
Schema.org has constructs like ItemList to capture ordering in collections. So far it has only been used for capturing the order of tracks in music albums and steps in recipes and howtos. But we could expand it to more domains or generalize it to a general construct that could be used everywhere, like we did with roles.

Re: scoring/tagging in general:
In order to capture not only the ordering but also the actual scores and/or tags associated with each item, we would need to generalize further itemList to capture those additional properties. Or we can just look into subclassing StructuredValue or one of its subclasses if we only want to capture a few use cases where scoring/tagging is important...

@VladimirAlexiev

This comment has been minimized.

VladimirAlexiev commented Aug 25, 2017

@nicolastorzec let's keep the discussion on ordering at #1727.
The connection to this issue is that in a list of ordered things, most often the first one is the preferred one. In this sense "ordering" is a more general concept than "preferredness".

To expand our mental horizons, the Getty ontology and editorial guidelines provide a lot more kinds of preferredness (the guidelines do it in various places, the link is to the most salient one):

  • skosxl:prefLabel, skosxl:altLabel (Preferred Flag for Language): single preferred label per language vs additional labels
  • prefLabelGVP (Preferred Flag): single label preferred by the Getty
  • prefLabelLoC (AACR Flag (LC heading)): a label preferred by the Library of Congress
  • broaderPreferred broaderNonPreferred (Preferred Parent Flag): main vs auxiliary parent of a concept (specialization of skos:broader)
  • contributorPreferred contributorAlternatePreferred contributorNonPreferred (Preferred Flag for Contributor): whether a contributor prefers a label or not
    "Alternate preferred" is used for several terms that are equally preferred by a contributor or in a source
  • sourcePreferred sourceAlternatePreferred sourceNonPreferred (Preferred Flag for Source): whether a source prefers a label or not

Getty TGN has these:

  • placeTypePreferred placeTypeNonPreferred

Getty ULAN has these:

  • agentTypePreferred agentTypeNonPreferred:
    Eg Obama is "president" (preferred) and "school teacher" (non-preferred)
    Eg Umbo is "artist" (preferred) and "photographer", "photojournalist" (non-preferred)
  • nationalityPreferred nationalityNonPreferred
  • biographyPreferred biographyNonPreferred: "biography" is a short description plus life dates
  • eventPreferred eventNonPreferred: eg Umbo was active (floruit) in Weimar, Berlin and Hannover and the first of these periods is considered preferred

So @nicolastorzec, +1 for "preferred in context" or "preferred by someone".
The big crux of the question is whether to model preferredness:

  • as a subproperty, eg skos/skosxl:pref/altLabel, the Getty examples above, schema:image vs primaryImageOfPage.
    PRO: simpler and more direct approach
    CONS: creates a proliferation of props (the Getty props are due to me but I'm not convinced it's the best way)
  • as an attribute in a separate node, eg ListItem.position (where position=1 can be interpreted as "preferred")
    PRO: stimulates appropriately abstract thinking (unlike primaryImageOfPage), same node can be used for extra info (eg who assigned or used a title, period of validity)
    CONS: quite verbose, see turtle example in #1727
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment