- From: Simon Spero <sesuncedu@gmail.com>
- Date: Fri, 13 Jun 2014 13:03:02 -0400
- To: Dan Scott <dan@coffeecode.net>
- Cc: "Wallis,Richard" <Richard.Wallis@oclc.org>, Gregg Kellogg <gregg@kellogg-assoc.com>, "<public-vocabs@w3.org>" <public-vocabs@w3.org>
- Message-ID: <CADE8KM5GGhTB-QCqNsQd4z9shqeDjMCiJSRb-h44QuKm113RNA@mail.gmail.com>
On Fri, Jun 13, 2014 at 9:57 AM, Dan Scott <dan@coffeecode.net> wrote: > On Fri, Jun 13, 2014 at 01:31:51PM +0000, Wallis,Richard wrote: > >> We could create Series as an Intangible base Type that could be used in >> combination with CreativeWork, Event etc. to produce the relevant series >> Type we are suggesting. >> > > Perhaps a more generic Series would use something like "seriesMember" (new > property) and "partOfSeries" (with a genericized, non-media-specific > definition) or "isPartOf" (with a range made even broader than > CreativeWork)? > This discussion and the ItemList related work seem to be growing together, or at least to be pointing their way towards some common abstraction. *Aggregations: * There is a need to represent some kinds of Things that have other Things as members/elements. - Class (schema:Class <http://schema.org/Class> , Cyc #$Collection <http://sw.opencyc.org/concept/Mx4rvViAzJwpEbGdrcN5Y29ycA>) : Aggregations whose members are defined by description (inten*s*ionally). Two Classes that have the same members are not necessarily the same thing. For example, the class Unicorn is not the same as the class Pegasus, even though they have the same (0) members. - Group: (Cyc #$Group <http://sw.opencyc.org/concept/Mx4rvVjmoJwpEbGdrcN5Y29ycA>) : Aggregations whose members are stated explicitly. There need be no ordering between group members, and the membership need not be constant over time. - Series (Cyc #$Series <http://sw.opencyc.org/concept/Mx4rvo5pTJwpEbGdrcN5Y29ycA>) : A group whose members are ordered by some total ordering. A series of ConceptualWorks <http://sw.opencyc.org/concept/Mx4rwU8mTJwpEbGdrcN5Y29ycA> is a ConceptualWork. *Properties:* All of these aggregations are Things, which means that they can have an identity; they can have names, descriptions ,etc. Groups need a property to specify members. Some Groups may only admit certain types of things as members; this expectation could be stated by a member type property to group definition. This could simplify the schema:member confusion, and maps neatly to microdata, OWL, and Cyc. It could also be used to simplify the generated documentation (cf. http://sdo-wip1.appspot.com/ProgramMembership ). Series whose members do not carry the information needed to calculate the desired ordering may require a property to carry this ordering. This property could be domain Thing; however, since the same individual might have different orderings in different Series, it is better to use something similar to ListItem. Note that ListItem has some possibly overly strong semantics; itemPosition *is* sufficient to specify the ordering, but it may not be *necessary.* For example one might want to mark up the results of an event where many people achieved the same score and rank; if three people tied for first place, one might want to give each of them the same rank; itemPosition does not appear to allow for this situation - it appears to impose a *strict* total order. ListItem also lacks any direct way to specify the series of which it is a member. It may be possible to create some simple abstractions that simplify several existing issues. Simon
Received on Friday, 13 June 2014 17:03:30 UTC