Re: Candidates for the CreativeWork property names vote off

>
>Perhaps this is a library-specific concept and we
>should use a library data property to make this distinction.

I don't disagree that there are library specific needs that will require
library specific properties to to make such distinctions clear.  Maybe
that is more the role of library focussed vocabularies - BIBFRAME?
However, those using Schema.org in a wider domain will still want to
describe relationships between CreativeWorks.


>different people will have different interpretations depending
>on what they have available to them.
>

So true, and it will be up to the data publisher to share their
understanding if we give them the [descriptive] tools to do so.  Just
because some may get it wrong (in our eyes) is no good reason not to.

~Richard.
>



On 28/03/2013 16:45, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

>The thing is, there is no way to prevent this from happening "in the
>wild" - different people will have different interpretations depending
>on what they have available to them. This is why the "abstract ->
>concrete" seems fragile to me. Someone will have two editions of Moby
>Dick and will want to connect them... while we can define a property for
>abstract <-> concrete, I doubt if we can make it clear how it is to be
>used. The current definition does not explicitly limit the usage to an
>abstract and a concrete thing. In part this is because of the way that
>CW has been defined -- it embodies the concrete. Some usages may only
>include what librarians would call "Work" properties, but there's
>nothing inherent in CW that would clearly separate an abstract Work from
>a published book. Any combination of properties is allowed, so you could
>have author/title/datePublished -- and wonder what exactly that
>represents. How do we define "abstraction" within CW?
>
>I think the problem here is CW and trying to use it for both abstract
>and concrete. If we have to have an abstraction in our metadata, then we
>may need to define one. Personally, I think it's early days to be trying
>to shoehorn this concept into schema.org, and I don't think it fits with
>what is already there. Perhaps this is a library-specific concept and we
>should use a library data property to make this distinction.
>
>kc
>
>On 3/27/13 7:33 PM, Young,Jeff (OR) wrote:
>> Ouch. The possibility of this interpretation is unacceptable to me:
>>
>> A -> oneOf -> B
>> B -> oneOf -> A
>>
>> I can't tell up from down anymore. It might even get confused for
>> sideways. If that's what will happen, then I would withdraw "oneOf" from
>> this list and suggest a different proposal for "seeAlso".
>>
>> BTW, that seems like an oddly good idea. Now if I could just remember
>> where I've seen it before. ;-)
>>
>> Jeff
>>
>> Sent from my iPad
>>
>> On Mar 27, 2013, at 4:56 PM, "Karen Coyle" <kcoyle@kcoyle.net
>> <mailto:kcoyle@kcoyle.net>> wrote:
>>
>>> Re: Candidates for the CreativeWork property names vote off
>>>
>>> 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 <http://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 <mailto: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 <mailto: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 Saturday, 30 March 2013 15:16:02 UTC