Re: Candidates for the CreativeWork property names vote off

Hi Karen,

I agree; you point out a very important thing here. The lack of an
explicitly abstract class can be a problem. As we know, for
schema:Product, the class <http://schema.org/ProductModel> exists for
a similar purpose (albeit it represents a prototype or a datasheet,
which differs from an abstraction). One option could be to generalize
this pattern (and the schema:model property) and introduce a base
schema:Model or schema:Prototype class.

However, I wonder if we instead can refocus, from a notion of
abstract/concrete to a notion of general/specific? In doing so, we can
avoid the need for an abstract class, and just say that some
schema:CreativeWork things are more generally conceived than others
(*).

It seems reasonable to expect schema:CreativeWork to be used to
describe things like books, art or games in various levels of detail,
making it plausible to distinguish between various levels of
specificity, rather than explicit levels of abstraction. Abstractions
refer to ideas, whereas generalizations refer to groups (see e.g.
[1]). And they bring different perspectives to mind. It is easier to
talk about "The Lord of the Rings" "in general", rather than "in
abstract form".

Perhaps another term would work better for this. I suggest:

12. represents

I think it would be fairly obvious to say that a specific form, like a
pocket or an audio-book, represents a more generally defined book.

Now, regarding the specificity of its definition. Reasonably,
schema:represents would have a domain of schema:CreativeWork. For the
range, we could either go with schema:CreativeWork, and limit the
definition to mean "represents a more generally defined notion of a
work". Or we could go with schema:Thing, and say that the thing
represented can be anything, from an abstract idea, via a general
schema:CreativeWork to even a physical occurrence of which the
representing creative work is e.g. a depiction.

Cheers,
Niklas

[1]: http://grammar.ccc.commnet.edu/grammar/composition/abstract.htm

(*): If this seems like troubling notions of "reality", it should be
pointed out that those are commonly vague and fleeting anyway. If we
want to describe a *real* book, do we mean it at a specific instance
in time? Do we consider it the same book if it loses the cover?
Temporality and mereology aren't easy once you start to unravel them.
A fair way of avoiding this philosophical abyss is to simply focus on
*shared* notions that we can leverage and intuitively grasp, and which
seem stable and pragmatic for our needs. It's good at times though, to
remember that this is not an absolute reality.


On Thu, Mar 28, 2013 at 5:45 PM, 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:14:52 UTC