Re: ItemList examples

On Aug 7, 2014, at 2:37 AM, 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?

Given the potentially broad use of Roles, explicitly adding them to the range of every property using them doesn't help, and it doesn't convey the semantics that the membership property used within a Role must be the same as the property referencing the role; these are just some of schema.org's evolving semantics.

My own reasoner (used in the Structured Data Linter) allows Role as the value of a property if that same property is used within the Role, and the value of that property is in range.

I think the same semantics work for a Role-based collection, but in that case the property is multi-valued and has an additional intermediate ListItem, although I could see circumstances where that was not used either, and it was really more like a multi-valued Role. The use of ListItem does make this similar to the Ordered List Ontology [1].

Gregg

[1] http://smiy.sourceforge.net/olo/spec/orderedlistontology.html


> --
> Markus Lanthaler
> @markuslanthaler
> 
>

Received on Thursday, 7 August 2014 17:03:17 UTC