Re: Voting for CreativeWork property names

Thanks, Karen.  This makes sense.  I also just went back over the thread on this - it's all kind of blur, I think my brain is blocking it as a self-defense mechanism.

So this seems to me that CreativeWork -> Book | Movie | etc. is a relationship that you generally wouldn't want to express, since the Work has a very high potential to be a "supernode" [1].  Instead, you're only ever really going to want to express the inverse relationship (Book -> CreativeWork), which sort of fits Alf's proposition.  So while 'work' might have overloaded meanings, since only one direction that needs to be modeled, is there another property name that could be used that doesn't require a preposition?  That said, there are plenty of many-to-one properties in schema.org that do have prepositions ('Movie:musicBy', 'MusicRecording:byArtist', 'MusicRecording:inPlaylist', 'CreativeWork:isBasedOnUrl'), so 'instanceOf', or 'isDerivedFrom', or whatever doesn't seem terribly out of character.

I have no real opinion on this, but I don't think we need to think of this as bidirectional relationship (well, not explicitly, anyway), if that inspires somebody to coin a property name that goes down smoother for everybody :)

-Ross.
1. http://thinkaurelius.com/2012/10/25/a-solution-to-the-supernode-problem/

On May 17, 2013, at 11:04 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:

> 
> 
> On 5/17/13 5:39 AM, Ross Singer wrote:
> 
>> 
>> I'm all for this suggestion, assuming that the object will always be a
>> Work.  I got the impression that this was kind of taking the same
>> approach as commonThing [1], where the subjects and objects can be of
>> ambiguous types, but maybe I'm conflating some unrelated threads here.
> 
> 
> Ross, there has been discussion on the calls about the nature of this relationship. Richard sees it as being a relationship between a Work (of a FRBR/BIBFRAME-ish nature) and an instance or example of that Work (Manifestation). It *is* intended to be hierarchical in nature.
> 
> Unfortunately, schema.org does not have a class that corresponds to this meaning of Work. CreativeWork is rather like MARC -- it has properties for a whole range of description, which, in the whole, describes a Manifestation with some properties that FRBR would consider to be Expression and Work.
> 
> The expected range of InstanceOf is CreativeWork, but that means that, depending on the data that has been supplied, the CreativeWork in the triple could have the properties of FRBR:Work, BIBFRAME:Work, or an entire bibliographic description encompassing FRBR:Work/Expression/Manifestation or BIBFRAME:Work/Instance.
> 
> Looking at it from a library point of view, one could create CreativeWork descriptions that are essentially BIBFRAME:Work, and then the related CreativeWork descriptions that are essentially BIBFRAME:Instances, and use this to connect them. That means coding a schema.org CreativeWork with physical description but no creator or subjects (a BIBFRAME:Instance) - something that I think would only be done by libraries.
> 
> To me this is all pretty shaky within the schema.org framework, and I don't think it really belongs there. If libraries need a library-specific way to do works and instances we should keep it out of schema.org.
> 
> My usual overly-long 2c.
> 
> kc
> 
> 
>> 
>> -Ross.
>> 
>> 1.
>> http://dilettantes.code4lib.org/blog/2011/11/why-do-we-obsess-over-frbr-entities/
>> 
>>> 
>>> Alf
>>> 
>>> On 16 May 2013 23:12, Wallis,Richard <Richard.Wallis@oclc.org
>>> <mailto:Richard.Wallis@oclc.org>> wrote:
>>> 
>>>    Hi Alf,
>>> 
>>>    The approach proposed was shaped by several factors including:
>>> 
>>>      *   CreativeWork describes "The most generic kind of creative
>>>    work, including books, movies, photographs, software programs, etc."
>>>      *   It is the super type for many specific types such as Map,
>>>    Painting, Movie, Book, Sculpture, etc.
>>>      * Schema.org <http://Schema.org> is a generic vocabulary with a
>>>    broad consumer community therefore domain specific terms should be
>>>    avoided if possible
>>>      *   We have specific guidance that Schema.org
>>>    <http://Schema.org> will never implement FRBR
>>> 
>>>    On that last point, your suggestion is leaning in a FRBR
>>>    direction. I can hear the follow on "we need  manifestation & item
>>>    properties"  already.
>>> 
>>>    Expression also has certain library-ish connotations
>>> 
>>>    CreativeWork->work I would suggest is a little confusing as to
>>> 
>>>    The hasInstance / instanceOf pair were proposed as generic and
>>>    directional properties.
>>> 
>>>    Following the vote about the need of 'is', I have some sympathy
>>>    with the suggestion of dropping the 'has' making it 'instance /
>>>    instanceOf'
>>> 
>>>    ~Richard
>>> 
>>>    From: Alf Eaton <eaton.alf@gmail.com
>>>    <mailto:eaton.alf@gmail.com><mailto:eaton.alf@gmail.com
>>>    <mailto:eaton.alf@gmail.com>>>
>>>    Date: Thursday, 16 May 2013 18:30
>>>    To: "public-schemabibex@w3.org
>>>    <mailto:public-schemabibex@w3.org><mailto:public-schemabibex@w3.org <mailto:public-schemabibex@w3.org>>"
>>>    <public-schemabibex@w3.org
>>>    <mailto:public-schemabibex@w3.org><mailto:public-schemabibex@w3.org <mailto:public-schemabibex@w3.org>>>
>>>    Subject: Re: Voting for CreativeWork property names
>>>    Resent-From: <public-schemabibex@w3.org
>>>    <mailto:public-schemabibex@w3.org><mailto:public-schemabibex@w3.org <mailto:public-schemabibex@w3.org>>>
>>>    Resent-Date: Thursday, 16 May 2013 18:30
>>> 
>>>    On 16 May 2013 17:55, Wallis,Richard <Richard.Wallis@oclc.org
>>>    <mailto:Richard.Wallis@oclc.org><mailto:Richard.Wallis@oclc.org
>>>    <mailto:Richard.Wallis@oclc.org>>> wrote:
>>> 
>>>    > I have reflected these choices in the proposal page
>>>    <http://www.w3.org/community/schemabibex/wiki/CreativeWork_Relationships>
>>>    > If people are happy with the proposal, I suggest that we should
>>>    add some html examples to the turtle and then submit to public-vocabs.
>>> 
>>> 
>>>    Would it be more straightforward to make is/has/of implicit and
>>>    just use simple property names that read well in both directions?
>>>    Like this, for example:
>>> 
>>>    <http://www.worldcat.org/oclc/38264520>
>>>    <http://proposed-schema.org/work>
>>>    <http://exampleworks.org/work/12345>.
>>>    <http://exampleworks.org/work/12345>
>>>    <http://proposed-schema.org/expression>
>>>    <http://www.worldcat.org/oclc/38264520>.
>>> 
>>>    Perhaps this has been proposed and rejected already?
>>> 
>>>    Alf
>>> 
>>> 
>> 
> 
> -- 
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
>

Received on Friday, 17 May 2013 15:37:18 UTC