W3C home > Mailing lists > Public > public-vocabs@w3.org > July 2013

Re: Proposal: Collection

From: Niklas Lindström <lindstream@gmail.com>
Date: Tue, 16 Jul 2013 15:02:34 +0200
Message-ID: <CADjV5jdeL8Z=-gnmdTKUOresK5syJUQt6T7Jfb79K775_KbyYA@mail.gmail.com>
To: "Wallis,Richard" <Richard.Wallis@oclc.org>
Cc: "Young,Jeff (OR)" <jyoung@oclc.org>, Dan Brickley <danbri@danbri.org>, "public-vocabs@w3.org" <public-vocabs@w3.org>
On Tue, Jul 16, 2013 at 2:25 PM, Wallis,Richard <Richard.Wallis@oclc.org>wrote:

>  Good idea referencing the DC Terms equivalents of these property names,
> indicating previous and parallel origins.
>

Great!

 Not so sure about explicitly saying that they're owl:equivalentProperty –
> would this not have the effect to constrain usage in Schema by definitions
> in DC. In this specific case I don't see an issue, but a principle that
> might cause problems later.
>

That is an important question. As you say, here there is no problem since
the DC terms are very broad (with e.g. no formal domain nor range). In fact
though, these Schema.org properties are probably rdfs:subPropertyOf the DC
terms, since in schema.org there will be both domain and range.

Of course, interlinking vocabularies does imply semantics. But as these are
defined and final, the social contract around them dictates that they
mustn't change. To some extent, the unwillingness to rely on this seems to
drive the reinvention of terms across vocabularies, every so often (again,
detrimental to integration). Some party should lead the way away from this
pattern. Given that schema.org is assimilating bits and pieces of other
vocabularies, I think structurally noting their origins is very valuable.
And if no property in RDFS/OWL is lax enough to avoid "semantic liability",
I'd say some schema-specific property for linking external properties, like
"closeMatch", or "isBasedOn", would be better than nothing.

Cheers,
Niklas



>  ~Richard.
>
>   From: Niklas Lindström <lindstream@gmail.com>
> Date: Tuesday, 16 July 2013 12:41
> To: Richard Wallis <richard.wallis@oclc.org>
> Cc: "Young,Jeff (OR)" <jyoung@oclc.org>, Dan Brickley <danbri@danbri.org>,
> "public-vocabs@w3.org" <public-vocabs@w3.org>
> Subject: Re: Proposal: Collection
>
>   Could we also add a section, similar to the Datasets proposal [1],
> stating that these properties are related to the Dublin Core properties
> [2], [3] of the same name?
>
>  (Perhaps even saying that they're owl:equivalentProperty. Ideally, the
> final proposal in HTML+RDFa (the proposals format prescribed by [4]) can
> contain this as an explicit triple, for precise and machine-actionable
> documentation. This would also eliminate various ongoing speculations on
> what origins or equivalencies various things in schema.org may or may not
> have, which is detrimental to data integration.)
>
>  Cheers,
> Niklas
>
>  [1]: http://www.w3.org/wiki/WebSchemas/Datasets#Related_vocabularies
> [2]: http://purl.org/dc/terms/hasPart
> [3]: http://purl.org/dc/terms/isPartOf
> [4]:
> http://www.w3.org/wiki/WebSchemas/SchemaDotOrgProposals#Proposals_for_Schema.org
>
>
>
> On Tue, Jul 16, 2013 at 1:23 PM, Wallis,Richard <Richard.Wallis@oclc.org>wrote:
>
>> Taking on the brief discussion, I have adjusted the text of this proposal
>> a little.
>>
>> Although, to broaden its applicability, the isPartOf property may best be
>> added to Thing, the proposal currently proposes it as a CreativeWork
>> property.
>>
>> Subject to feedback, and adding a markup example, I will post this on to
>> the WebSchemas Wiki in the next few days.
>>
>> ~Richard.
>>
>> On 07/05/2013 16:09, "Young,Jeff (OR)" <jyoung@oclc.org> wrote:
>>
>> >Here are some thoughts about Dan's question of the difference between
>> >Collection and Class. In a sense, this is splitting an arbitrary hair
>> >because both are identifiable sets of individuals. I think there are a
>> >few ways to decide, but ultimately it's probably a matter of perspective
>> >and intuition.
>> >
>> >Perhaps one way to decide the art is to ask whether the individuals have
>> >properties that are peculiar to them being in the my:Foo set or not. If
>> >there are such properties, then my:Foo should be a Class so it can act as
>> >a domain/range on those properties. Another criteria could be whether
>> >my:Foo makes sense as a subclass/superclass of another Class in the
>> model.
>> >
>> >Whether my:Foo can be a schema:Class AND a schema:Collection boils down
>> >to DL or not to DL. I like to be careful about those things, but I can
>> >cope with people who aren't.
>> >
>> >Jeff
>> >
>> >> -----Original Message-----
>> >> From: Wallis,Richard [mailto:Richard.Wallis@oclc.org]
>> >> Sent: Tuesday, May 07, 2013 9:11 AM
>> >> To: Dan Brickley
>> >> Cc: public-vocabs@w3.org
>> >> Subject: Re: Proposal: Collection
>> >>
>> >> >
>> >> >Is this specifically library-like or cultural heritage notion of a
>> >> >collection? Or is it a general purpose data structure for listing
>> >> >bundles of things? My suspicion is that it's the latter, but it could
>> >> >easily be mistaken for a very general purpose mechanism.
>> >>
>> >> You suspect correctly.  The need/approach has come the library and
>> >> associated worlds, but it is clearly applicable in a wider context.
>> >>
>> >> A library has a collection of books, a museum has a collection of
>> >> artefacts, etc.   However a farmer could have a collection of animals
>> >>
>> >> By making Collection a subclass of CreativeWork it does imply that the
>> >> creation of a collection would be a conscious creative act by a
>> >> creating person/organization.
>> >>
>> >> However the parts of a collection would not always be creative works
>> >> themselves (fossils in a museum, toys and books in a children's
>> >> library,
>> >> etc.) hense the need for isPart to be added to Thing.
>> >>
>> >>
>> >> >
>> >> >If there's a bibliographic / cultural heritage problem we can solve
>> >> >here, while avoiding getting into heavier 'theory of parts' territory
>> >> >(e.g. http://ontology.buffalo.edu/smith/articles/Mereotopology.pdf)
>> >> >I'd be happy...
>> >>
>> >> I have equal aversion to diving down such deep dark rabbit holes!
>> >>
>> >> Would we not avoid that by indicating that a Thing can be part of many
>> >> collections or none, a Collection can contain zero or any parts that
>> >> may or may not be in other Collections - or am I being naive? ;-)
>> >>
>> >> ~Richard.
>> >> >
>> >> >Dan
>> >> >
>> >> >
>> >> >> Sub-classed to: Thing > CreativeWork > Collection Properties likely
>> >> >> to be used from CreativeWork
>> >> >> * about (e.g. for collection themes)
>> >> >> * contentLocation (e.g. for museum/archive collections)
>> >> >> * creator (e.g. for collection curators)
>> >> >>
>> >> >> New property for CreativeWork (or perhaps for Thing)  As a matter of
>> >> >>principle, anything imaginable can be thought of has having  parts.
>> >> >>Although we are primarily interested in this property for sake of
>> >> >>modelling collections and multi-part works, a broader treatment as a
>> >> >>property of schema:Thing would be appreciated.
>> >> >> * Property: hasPart
>> >> >> * Expected Type: Thing
>> >> >> * Description: A thing that is part of this CreativeWork. For
>> >> example
>> >> >>things in a collection or parts in a multi-part work
>> >> >>
>> >> >> New property for Thing
>> >> >> This is the same schema:isPartOf property as currently found in the
>> >> >>http://schema.org/WebPage class with schema:CollectionPage as the
>> >> range.
>> >> >> We would like it promoted for broader use, particularly in this
>> >> case,
>> >> >>for  use with a Collection Type.
>> >> >> * Property: isPartOf
>> >> >> * Expected Type: CreativeWork or Thing(dependant on choice for
>> >> >>hasPart)
>> >> >> * Description: Inverse of hasPart
>> >> >>
>> >> >> More information and some examples can be found on the
>> >> >> SchemaBibExtend Wiki
>> >> <http://www.w3.org/community/schemabibex/wiki/Collection>.
>> >> >>
>> >> >> ~Richard.
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>>
>
Received on Tuesday, 16 July 2013 13:03:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:28 UTC