- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sun, 31 Mar 2013 10:39:07 -0700
- To: public-schemabibex@w3.org
Niklas - This is a bit off the side of this discussion, but when I look at schema.org I see a lot of what I would call "static product description." schema.org is mostly about *things* with very little use of relationships. This makes sense if you think about the primary role of search engines and the fact that they display results as lists, not as graphs. (hopefully that will change). This means that schema.org doesn't have many thing-to-thing relationships, that is, relationships between properties or even between classes, other than class membership. In the bibliographic area, the real excitement will come from the use of non-structural relationships, like "inspired by" "quotes" "derives from" "satirizes" etc. I think it would be interesting to have the conversation the vocab list about property relationships. What is the best way to move from a rather linear, noun-based description to a more dynamic, relationship-based set of verbs? What will those mean for search and display? Should we be coordinating this evolution across vocabularies? kc On 3/30/13 8:13 AM, Niklas Lindström wrote: > 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 >> > > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Received on Sunday, 31 March 2013 17:39:39 UTC