Re: Schema.org property cardinality and use of plural (WAS Re: SoftwareApplication proposal for schema.org)

On 24 February 2012 21:25, Will Norris <will@willnorris.com> wrote:
> I had the same question when I first started looking at this.  There is a
> certain simplicity in not requiring microdata vocabularies to define
> cardinality of properties, and leaves the door open to interesting use cases
> that may not have been initially imagined.

Yes. Well there are two things here: do we define a cardinality, and
do we also bake that cardinality into the property name with an
English plural 's' (or it's absense)?

I'm in favour of defining cardinality when it makes sense to do so
(and in the full expectation people will ignore or mess up whatever we
try to impose). But I don't think the experiment of using plural 's'
markers has worked well. It would be better to use properties of
properties and publish those in the schema.org site.

http://schema.org/Person has 'spouse' rather than 'spouses'. Are we
really to assume the property can have at most one singular value?
What about re-marriage, or societies (the Web having global reach)
where multiple spouses are common? Never mind historical data, the
Bible, etc. I'd much rather see cardinality expressed schematically
than through spelling, since changing the expected spelling has impact
on a *lot* of instance data.

> That said, there is the practical need for implementors to make a decision
> on how they're going to handle multiple occurrences of properties which they
> assumed to be singular.  What happens when a Person has multiple name
> properties?  It's up to each implementor to decide, and the worse case is
> for drastically different implementations to arise such that publishers
> don't know what to expect.

Yup

> I would love to see cardinality take the same approach as types.  From the
> conformance section of http://schema.org/docs/datamodel.html:
>
>> While we would like all the markup we get to follow the schema, in
>> practice, we expect a lot of data that does not. We expect schema.org
>> properties to be used with new types. We also expect that often, where we
>> expect a property value of type Person, Place, Organization or some other
>> subClassOf Thing, we will get a text string. In the spirit of "some data is
>> better than none", we will accept this markup and do the best we can.
>
>
> I think the same would apply to cardinality.  We provide guidance on
> expected cardinality of properties, but always do the best we can with
> whatever we get.

Yes. With FOAF we declared some properties as having 'at most one
proper value', or implying that
there can be at most one entity with any given value. Sites got it
wrong all the time, but at least the
declaration helped track down some data problems.

> To address the original question, I think singular and plural naming of
> properties is certainly one way (though not the only way) to imply the
> expected cardinality of a particular property.  Yes, you get the somewhat
> unusual mismatch of naming each individual instance with a plural name, but
> you're always going to run into this certain cases.  If were you use
> singular naming, you get weird results when you following the specified JSON
> mapping:
>
> {
>   "type": "http://schema.org/Person",
>   "properties": {
>     "child": [ { ... }, { ... } ]
>   }
> }

If we have to choose between the JSON being a bit weird, or the
HTML-based markups being a bit weird, I would go for the former. JSON
feeds are relatively invisible, whereas the HTML source has a wider
and more varied audience. Also the plural form looks odd in both
microdata and rdfa notations.

> This same problem occurred with PortableContacts when you compare the XML
> and JSON
> representations: http://portablecontacts.net/draft-schema.html#anchor5.  For
> what it's worth, PoCo used plural naming where properties were expected to
> be multi-valued.  Unfortunately, we already have examples in Schema.org
> where properties that I would expect to be plural have a singular name (i.e.
> Person/affiliation).

Yup, it's hard designing a schema to work nicely in two quite
different syntaxes.

cheers,

Dan

Received on Thursday, 1 March 2012 18:02:29 UTC