Re: Proposals

Richard, all,

It's great to see this progress!

However, I do wonder if we shouldn't just import "hasPart" and
"isPartOf" verbatim from Dublin Core? From the DC Terms vocabulary
definition:

  - - - 8< - - -

    @prefix dct: <http://purl.org/dc/terms/> .
    @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
    @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

    dct:hasPart a rdf:Property ;
        rdfs:label "Has Part"@en-US ;
        rdfs:comment "A related resource that is included either
physically or logically in the described resource."@en-US ;
        rdfs:isDefinedBy dct: ;
        rdfs:subPropertyOf dct:relation .

    dct:isPartOf a rdf:Property ;
        rdfs:label "Is Part Of"@en-US ;
        rdfs:comment "A related resource in which the described
resource is physically or logically included."@en-US ;
        rdfs:isDefinedBy dct: ;
        rdfs:subPropertyOf dct:relation .

  - - - >8 - - -

These terms have been used for many years in all kinds of situations,
proving that their open-ended definitions (no specific domain nor
range) make them applicable for e.g.:

 * collections of items (like a trilogy, or a sales offer)
 * books and chapters (a pattern recommended by e.g.
<http://purl.org/ontology/bibo/>)
 * serials
 * compositions of physical things
 * .. etc.

I would recommend to explicitly "import" these. (Same definitions in
prose; using Thing for both domain and range. And explicitly link to
them in the proposal.) The specific "nature" of the composition can
often be determined by the types of the things in the hasPart/isPartOf
relation. (And anything more specific can be defined by making a
subproperty of these properties in turn, by more specific vocabularies
than schema.org.)

We could also do the same with
<http://purl.org/dc/dcmitype/Collection>. In fact, cherry-picking from
Dublin Core would make sense for us in general (as it is a generic,
well-known and widely used vocabulary).

.. Alas, the schema.org "import" practice doesn't yet state relations
to these commonly known terms from other vocabularies (leaving this up
to e.g. <http://schema.rdfs.org/> after the fact – i.e. when semantic
divergence may already have happened). I still recommend to always
explicitly do so whenever possible. My hope is that this will be
expressed directly at the RDF level at some point. (Of course, were it
not for the current popularity and easiness of the schema.org "one
size fits all", I would recommend to just use DC terms directly.)

(Personally, I am very wary of "babelization". My engagement in RDF
partly stems from the pain of working in the IT industry where
gratuitous reinvention is commonplace (resulting in *massive* waste
and lost interoperability), so I am rather vigilant on this point. ;)
Though yes, I know that the value of doing such coordination can be
debated too, and that semantic drift can result by ill-informed
"repurposing" of terms. But by being precise, such misuse is much
simpler to detect.)

Cheers,
Niklas


On Fri, Mar 22, 2013 at 1:05 PM, Wallis,Richard <Richard.Wallis@oclc.org> wrote:
> Following yesterday's meeting:
>
>
>   *   Citation<http://www.w3.org/community/schemabibex/wiki/Citation> – Proposed to the public-vocabs list <http://lists.w3.org/Archives/Public/public-vocabs/>.
>   *   Parts<http://www.w3.org/community/schemabibex/wiki/Parts> – Merged into Collection.
>   *   Collection<http://www.w3.org/community/schemabibex/wiki/Collection> – Updated to include Parts examples & wording.  Now ready for proposing to public-vocabs, in about a week.
>   *   Work-Instance – Following conversation on list after the meeting I have renamed the proposal to CreativeWork Relationships<http://www.w3.org/community/schemabibex/wiki/CreativeWork_Relationships> and tweaked the wording a little, but have not yet changed 'instance' to 'derivative' - see following email.  - Hopefully we can still propose this in a couple of weeks time.
>
> ~Richard.
>
>
>
>

Received on Friday, 22 March 2013 22:05:05 UTC