- From: Wallis,Richard <Richard.Wallis@oclc.org>
- Date: Sat, 30 Mar 2013 15:15:33 +0000
- To: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
> >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