W3C home > Mailing lists > Public > public-vocabs@w3.org > August 2014

Re: ItemList examples

From: Jarno van Driel <jarnovandriel@gmail.com>
Date: Fri, 8 Aug 2014 08:49:07 +0200
Message-ID: <CADK2AU2yr+TJkPEVMRmxqA5Znhpot6MJW-c4BMzR0bM2gZa6oQ@mail.gmail.com>
To: "Wallis,Richard" <Richard.Wallis@oclc.org>
Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, "<public-vocabs@w3.org>" <public-vocabs@w3.org>
>
> 1. A grouping of things, with no particular ordering implied, the minimum
> connection between those things being that they members of the group.  Such
> membership not preventing them being members of other groupings.


Now if we're talking about a generic group of things, couldn't
WebPageElement be used for this:
https://www.w3.org/wiki/WebSchemas/ChainingLayoutElements#CollectionPage.2C_WebPageElement.2C_ImageObject
 ?
(minus the @mainContentOfPage, that's there on behalf of a different
discussion:
http://lists.w3.org/Archives/Public/public-vocabs/2014Aug/0070.html)

2. A grouping of things in which some form of ordering is applied,
> numerical, alphabetical, order of insertion, or even on the whim of the
> person or application that

defines the group. In my world I would call this a list, but as I say
> naming is secondary.


Besides proposing to use WebPageElement for this as well (and adding the
properties for ordering and such to CreativeWork so other subClasses can be
ordered as well), might there be any sense in also looking at what's
happening to <ol> in HTML5 (http://html5doctor.com/ol-element-attributes/).
Maybe taking this into account can help keep the final solution close to
what website developers will be/are using for everyday coding. Which does
make it easier to understand for a lot of them.

And if we apply this to a WebPageElement then we can also define the order
of WebPageElements on a WebPage. And since it has been expressed on
numerous occasions (outside of this mailing list), search engines care
about the order of elements on a page as to help decide the
importance/value of any given element I think it could help not having
those properties solely for list purposes.

3. A grouping functionally the same as 1. but a subtype of CreativeWork so
> that the creative efforts in producing it can be described.


Would this do the trick:
https://www.w3.org/wiki/WebSchemas/ChainingLayoutElements#CollectionPage.2C_ItemList.2C_Product
(and of course ItemList would keep all properties of CreativeWork to
express the creative efforts involved)

4. A grouping functionally the same as 2.. but a subtype of CreativeWork so
> that the creative efforts in producing it can be described.


Wouldn't this be feasible if the same final solution as [2] is used only
then using ItemList as opposed to a WebpageElement (that has parts)?


2014-08-07 16:27 GMT+02:00 Wallis,Richard <Richard.Wallis@oclc.org>:

>  Firstly just a bit of background on why the name Collection was chosen in
> the Collection proposal from SchemaBibExtend.
>
>  Collection has specific meaning in the world of libraries museums
> galleries, and the wider world  - there are many folks sporting the title
> Collection Manager.  All the books in a library is referred to as the
> library’s collection, museums, and galleries curate and manage their
> collections. - There is the Getty Collection, the National Numismatic
> Collection in the Smithsonian, contains over 450,00 coins and medals - I
> could go on but i won’t…
>
>  Naming is obviously important but secondary in my mind to us being able
> to satisfy 4 separate but connected needs around this to describe:
>
>
>    1. A grouping of things, with no particular ordering implied, the
>    minimum connection between those things being that they members of the
>    group.  Such membership not preventing them being members of other
>    groupings.
>
>    2. A grouping of things in which some form of ordering is applied,
>    numerical, alphabetical, order of insertion, or even on the whim of the
>    person or application that defines the group.  In my world I would call
>    this a list, but as I say naming is secondary.
>
>    3. A grouping functionally the same as 1. but a subtype of
>    CreativeWork so that the creative efforts in producing it can be described.
>
>    4. A grouping functionally the same as 2.. but a subtype of
>    CreativeWork so that the creative efforts in producing it can be described.
>
>
>  Beyond these four basic needs, there needs to be some utilities, mostly
> for members of the ordered examples, to identify first, last, next
> previous, and possibly sub-groupings (pages).  This last capability could
> be achieved by describing an ordered grouping the member of which are
> themselves ordered groupings for page1, 2, etc. or perhaps ‘A-M’, ’N-Z’.
>
>  I have deliberately have avoided using terms such as collection, list,
> item etc. to separate out the names from the functionality.  However in
> retrospect ‘Group’ could be a possible name for a collection of unordered
> things.
>
>   ~Richard
>
>  On 7 Aug 2014, at 05:37, Markus Lanthaler <markus.lanthaler@gmx.net>
> wrote:
>
> On 7 Aug 2014 at 10:09, Dan Brickley wrote:
>
> On 7 August 2014 04:42, Gregg Kellogg wrote:
>
> On Aug 6, 2014, at 7:49 PM, Jason Douglas wrote:
>
> I suppose the backward-compatible way to do it would be to:
>
> Create a new type (Collection?)
> Change the domain of the structural properties of ItemList to Collection
> Make ItemList inherit from Collection as well as CreativeWork
>
> That leaves ItemLiist as the editorial thing, so all existing markup would
> still be semantically unchanged.
>
>
> That's where I ended up - but it feels backwards. Note that
> "Collection" is being proposed by the bibextend folk for the editorial
> thing:
> http://www.w3.org/community/schemabibex/wiki/Collection#New_Type:_Collection
>
> "This is a collection in the broadest and simplest possible sense. It is
> a set of CreativeWorks or Things. The things in a collection may be
> thought of as its "parts", even though the membership could be
> ephemeral. The defining of a Collection, by bringing, identifying, or
> linking together a collection of things, is considered to be a creative
> act, hence a Collection is a more specific type of CreativeWork."
>
> I think Collection makes a lot of sense. To me, ItemList sounds like a
> curated list, whereas Collection sounds like a basic grouping.
>
>
> My intuitions run the other way. Collection slightly emphasises the
> act of bringing together, ItemList sounds like a made up data
> structure word.
>
>
> What about simply using List?
>
> I'm still a bit on the fence whether it is really a good idea to use the
> Role design for such a basic data structure. Do we plan to add (Item)List
> to the range resp. support it as value of just about every property?
>
> In Hydra (which also has to work with vocabularies that might use
> rdfs:range and would thus break such a design) we solved this by
> introducing an explicit indirection and describing what relationship the
> collection manages; similar to hasRole that was discussed a while ago. So,
> Greggs example
>
>  {
>    "@context": "http://schema.org",
>    "@type": "SportsEvent",
>    "@id": "/world-series/2013",
>    "name": "2013 World Series",
>
>    "subEvent": {
>      "@id": "/world-series/2013/subEvents",
>      "@type"; "ItemList"
>    }
>  }
>
> would instead be expressed as
>
>  {
>    "@context": "http://schema.org",
>    "@type": "SportsEvent",
>    "@id": "/world-series/2013",
>    "name": "2013 World Series",
>
>    "collection": {
>      "@id": "/world-series/2013/subEvents",
>      "@type"; "Collection",
>      "manages": { "subject": "/world-series/2013", "property": "subEvent" }
>    }
>  }
>
> The list items at /world-series/2013/subEvents then also express their
> relationship to /world-series/2013 explicitly instead of depending on some
> sort of inference.
>
>
> Btw. none of the new Role types have been added to any range so far making
> them very difficult to discover IMO. Are there plans to change that?
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
Received on Friday, 8 August 2014 06:49:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:49:34 UTC