Re: proposal just for article

On Tue, Dec 10, 2013 at 11:18 PM, Dan Scott <denials@gmail.com> wrote:

> On Tue, Dec 10, 2013 at 4:58 PM, Niklas Lindström <lindstream@gmail.com>
> wrote:
>
> <snip>
>
> > (And I'd like to reduce the set of properties where possible. I prefer to
> > use partOf/hasPart instead of distinct properties for each possible
> range,
> > unless required by use cases. Externally linked parts/containers can be
> > typed too, to mitigate the risk of consumers not getting the nature of
> the
> > composition.)
>
> Agreed, but as noted previously I was adopting the approach used by
> Series/Season/Episode as a means of not building too many
> prerequisites into the proposal. Managing scope and all that.
>

Sure, I see your reasoning. And there is information in a specific
subproperty with a dedicated range. But as we all noticed, it can become
unwieldy. (It seems like a good time to refactor.) The combination of
isPartOf and type of the object will probably suffice to get the nature of
the relationship. It seems to in our examples.

(Of course, a stand-alone article on FRBR glued onto an issue of Spider-man
#131 will break that assumption.)


> A strategy I've been musing about, though, was to bring forward the
> proposal to public-vocabs with the full set of partOf*/has*
> properties, but mention something like "Note that this introduces 6
> new hasPart/partOf* properties, and that's only likely to grow over
> time; we also happen to have this Collection proposal [1] that would
> solve this problem generally. Wouldn't that be nice? Would you like to
> see an alternate version of this proposal that uses Collection?"
>
> 1. http://www.w3.org/community/schemabibex/wiki/Collection
>

Like Karen, I too like that approach.

Cheers,
Niklas