Re: Candidates for the CreativeWork property names vote off

Ah, yes, that is definitely valuable information.

That was partly in my mind when I wrote the PS about related
vocabularies, since both those two ("realizes" and "embodies") and
suggestion 4 ("expressionOf", alternatively "expresses") are in "FRBR
territory". Which is why I kind of like "instanceOf" after all, since
it seems fairly neutral in that regard (albeit not in regard to other
domains). Still, I also think that it is quite ok if the property
we're after differ in precise meaning from FRBR even though we pick
the same name (as in "keyword"). As long as we're explicit about it
and feel that the benefits outweigh risks of confusion.

Of course, the ideal is probably to find something spot on and unused.
But, in principle, I believe that while it may be prudent to avoid
terms that FRBR has "taken" (since we're aiming for something more
generalized), we should only do so unless we end up with something
less intuitive (too vague, or too cryptic) as a result.

Cheers,
Niklas


On Thu, Mar 28, 2013 at 12:49 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>
>
> On 3/27/13 4:34 PM, Niklas Lindström wrote:
>>
>> I'd like to add:
>>
>> 10. embodies / embodiedBy
>
>
> Just for the record, FRBR uses:
>
> Expression -> realizes -> Work
> Manifestation -> embodies -> Expression
>
> That's not a vote for or against, just for information.
>
> kc
>
>
>>
>> , representing levels of concretization/abstraction (and hence not
>> being symmetric properties). I say "levels" since I think it's ok to
>> use it to describe "partial embodiment", such as an "expression" of a
>> "work", although it's probably most apt for describing a simpler
>> abstract/concrete relation (like "instanceOf" in BibFrame).
>>
>> Like Karen I prefer simple property names to the "has ..." form in
>> general. In schema.org, there is only one such form right now
>> (schema:hasPOS), and a bunch of properties as simple verbs in s-form
>> (noticeably schema:mentions, which has a domain of
>> schema:CreativeWork). I don't know if there is a convention in
>> schema.org on inverses (no property is described with owl:inverseOf,
>> so it's hard to be sure), but there are three properties ending in
>> "By" (schema:affectedBy, schema:musicBy and schema:reviewedBy).
>>
>> In order to not expand the list of choices too much, how about folding
>> 8 and 9 into 1 and 3 respectively, and vote on the form separately?
>> (Thus meaning that the alternate form of 2 is "concretizes", 4 is
>> "expresses" and so on.)
>>
>> (Also, I agree with Jeff that avoiding superfluous inverses is a good
>> thing, at least in principle. I fear that the world of markup-embedded
>> metadata may call for more dirty approaches though, and it seems to be
>> a trend to sprinkle a little of everything into the mix without much
>> notion of "primary data" nor expectations on consumption (including
>> collation and bidirectional statement traversal). We'll see how
>> various guidelines develop over time.)
>>
>> Cheers,
>> Niklas
>>
>> (PS. Once we're settling on something, it's probably wise to declare
>> what (if any) relations that suggestion has to DC (e.g. hasFormat),
>> BibFrame (instanceOf) and particular properties in the various FRBR
>> vocabularies actively used in the wild (including metalex). And
>> perhaps what we come up with here will also influence the ongoing
>> development of BibFrame.)
>>
>>
>> On Wed, Mar 27, 2013 at 9:55 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>>>
>>> I do think oneOf should be on the list. Also, I'm not fond of the
>>> "has..."
>>> form of property names. I prefer something that sounds more like a
>>> relationship than "has a thing" - So I"d add:
>>>
>>> 8. instantiates
>>> 9. realizes
>>>
>>> I think that the inverse relationships imply that the relationship be
>>> directional, whereas without the inverse the relationship is more open.
>>> In
>>> fact,
>>>
>>> A -> oneOf -> B
>>> B -> oneOf -> A
>>>
>>> makes perfect sense to me.
>>>
>>> Not all of the terms (hasInstance, hasConcretization) can be used in this
>>> way, which is why I don't suggest a non-inverse form for each of them.
>>> However, we are back to the difference between Work/Instance and
>>> "commonEndeavor" (for which Jeff's 'oneOf' would be an interesting
>>> substitute).
>>>
>>> kc
>>>
>>>
>>>
>>>
>>> On 3/27/13 1:04 PM, Young,Jeff (OR) wrote:
>>>>
>>>>
>>>> At the risk of distracting people from my favorite, I would re-offer:
>>>>
>>>> oneOf
>>>>
>>>> without an inverse property. There are plenty of properties in
>>>> Schema.org that don't have an inverse, so this shouldn't be unusual to
>>>> them.
>>>>
>>>> Jeff
>>>>
>>>>> -----Original Message-----
>>>>> From: Wallis,Richard [mailto:Richard.Wallis@oclc.org]
>>>>> Sent: Wednesday, March 27, 2013 3:58 PM
>>>>> To: public-schemabibex@w3.org
>>>>> Subject: Candidates for the CreativeWork property names vote off
>>>>>
>>>>> Following Antoine's suggestion and little consensus as to the names
>>>>
>>>>
>>>> for
>>>>>
>>>>>
>>>>> the CreativeWork properties currently documented as hasInstance &
>>>>> isInstanceOf - I am preparing to have a vote on it.
>>>>>
>>>>> So this is the first part of the process - assembling the candidates.
>>>>>
>>>>> Here is a few of what I remember having seen and heard in threads and
>>>>> discussions - please add others I have missed or that you think of
>>>>
>>>>
>>>> over
>>>>>
>>>>>
>>>>> the next few days.  I will close the candidate list on 31st March.
>>>>>
>>>>>
>>>>>     1.  hasInstance/instanceOf
>>>>>     2.  hasConcretization/concretizationOf
>>>>>     3.  hasRealization/relaisationOf
>>>>>     4.  hasExpression/expressionOf
>>>>>     5.  hasExample/exampleOf
>>>>>     6.  hasDerivative/derivativeOf
>>>>>
>>>>> ~Richard
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Karen Coyle
>>> kcoyle@kcoyle.net http://kcoyle.net
>>> ph: 1-510-540-7596
>>> m: 1-510-435-8234
>>> skype: kcoylenet
>>>
>>
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet

Received on Thursday, 28 March 2013 00:26:58 UTC