- From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
- Date: Wed, 9 Oct 2013 16:54:01 +0200
- To: kcoyle@kcoyle.net
- Cc: "public-vocabs@w3.org" <public-vocabs@w3.org>
Quick response: With "facets", I mean the ability combine multiple types (often such representing roles) at markup-time (i.e. at the level of instances) rather than at the schema level.
Afaik, that is not exactly what facets mean in library science, since there you typically have an understanding of a structure, which will be populated by the actual facet value.
But I would argue that my use of facets is just generalizing the idea of facets.
Martin
On Oct 8, 2013, at 6:08 PM, Karen Coyle wrote:
>
>
> On 10/8/13 7:50 AM, Martin Hepp wrote:
>> Karen:
>>
>> I agree with all what you say, but except for the fact that it is not said very clearly,
>
>
> Gee, thanks. :-(
>
> Perhaps we speak different languages. I'm here to learn, myself, and would hope that others are also willing to listen to what I have to offer. And I hope that "speaking like a librarian" isn't out of bounds.
>
>
> the notion of "facets" that can be combined for multi-typed entities is already inherent to schema.org.
>
>
> I am not sure that we are talking about the same thing. As Guha pointed out, the preference in schema.org is to make all types explicit. That was his response to my statement, "multiple typing within schema.org has been done explicitly in the design of classes and properties rather than being relegated to instances and reasoners." That is a statement that schema uses pre-coordination in its design.
>
> I'm talking about using post-coordination. However, that may not fit with the business case for schema (as per Guha's response). I am ignorant of the uses that the search engines envisage making of the data, so I have no idea what works or doesn't work for them. I personally think that post-coordination is easier for data creators and metadata maintainers.
>
>
>>
>> For instance, Offer is subordinate only to Intangible, nothing else.
>
>
> If you look at http://schema.org/offers, you see the types it is "used on." That is pre-coordination. Any type is available for pre-coordination with other types, AFAIK, within the conceptual limits of its hierarchy. I'm saying that some types might be designated for post-coordination because of their wide-spread use so that one doesn't have to decide a priori everything that you will express with your data. We use this in library classifications (even the traditional hierarchical ones) to allow anyone to add certain qualities, like time and place, to any topic at the time of data creation.
>
>
>>
>> Since there are no disjointness axioms in schema.org, one can freely combine types if that makes sense, and search engines will learn to understand useful combinations.
>>
>
>> Hierarchy in knowledge organization systems is overrated in terms of what it empowers computers to do over data, and it complicates the process of agreeing upon conceptual elements.
>>
>
> We definitely do agree on that. Yes, I think that the display of schema as a hierarchy is problematic. Although some folks here have absorbed sophisticated SemWeb concepts and can see beyond what looks like a strict hierarchy, others of us are still either often or always thinking in old-style Aristotelian terms. If a different presentation would help people use schema.org, then it would be worth considering. Since none of the types is disjoint, surely it isn't necessary to employ a hierarchical display. As an example, the LOV vocabularies' display[1], with any vocab able to occupy the "middle" of a graph, makes quite a bit of sense to me.
>
> kc
> [1] http://lov.okfn.org/dataset/lov/
>
> kc
>
>
>
>> Martin
>>
>> On Oct 8, 2013, at 4:34 PM, Karen Coyle wrote:
>>
>>> Guha, thanks for confirming the way I was reading the schema.
>>>
>>> As DanBri has heard me say, there is some irony in the tendency of Semantic Web development to lean heavily on hierarchy when its goal is to create a graph. Hierarchies, as we see here, are traps that we humans too easily fall into. It is obvious to me that if our data is to be a graph, our vocabularies also need to be graph-like, not hierarchical.
>>>
>>> Any "thing" can be offered. Any "thing" can have a location, exist in time, be acted on. Some combinations may not make sense (you don't manufacture cats and you don't take the appendix out of a stone), but it's probably better to allow volcanoes to have fax machines than try to define everything "correctly." Usage will win out in the end.
>>>
>>> I have mentioned before the concept of facets.[1] The pre-computing idea of facets was fairly restrictive due to physical restrictions,[2] but today we could have more freedom. Offer could stand alone, as could geographical location, as could some concept of "operating as a business or service" that includes street addresses. Hours of availability could apply to professors as well as stores and government offices and TV shows.
>>>
>>> There could still be some restrictions, so as not to go too far beyond what "normal people" think about the data they are marking up and to provide guidance. You could limit creators to CreativeWork and manufacturers to Product. (This seems to be the subtext behind those two types.)
>>>
>>> I see this as being inherently practical, not theoretical. What combinations do we think we need? In the development of schema, someone saw that Product needed offer, but didn't realize that other things might need offer as well. Offer has proven itself to be of general use and could be given the status of a facet that can be used wherever needed. It would no longer be subordinate to Product, but would stand alone (sub to Thing). In terms of how it would be used, there are choices: it could either be declared a super-type to particular types, or could be declared in instance data as an additional type, or could be considered to be available to instance data without an explicit declaration, as inherent in the use of any schema.org type.
>>>
>>> kc
>>>
>>> [1] https://en.wikipedia.org/wiki/Faceted_classification
>>> [1] https://en.wikipedia.org/wiki/Colon_classification
>>>
>>>
>>> On 10/7/13 8:54 PM, Guha wrote:
>>>> Absolutely. The assumption is that if an entity is an instance of
>>>> multiple types, this should be stated explicitly (as opposed to using a
>>>> property from a different type and expecting a reasoner to infer the type).
>>>>
>>>> Guha
>>>>
>>>>
>>>> On Mon, Oct 7, 2013 at 7:01 PM, Karen Coyle <kcoyle@kcoyle.net
>>>> <mailto:kcoyle@kcoyle.net>> wrote:
>>>>
>>>> Something else that has made it hard for me to generalize from the
>>>> use of product ontology to the use of additional schema.org
>>>> <http://schema.org> types is that the product ontology use provides
>>>> an additional type but no additional properties. It feels kind of
>>>> like an aside. The schema.org <http://schema.org> use case seems to
>>>> provide different capabilities, and has a more substantial impact on
>>>> the instance metadata.
>>>>
>>>> Admittedly, there was the quote that flew through here today saying
>>>> that proper reasoners would infer from the properties that one was
>>>> making a statement about additional types, but it does not seem that
>>>> that assumption has been in force during most of the development of
>>>> schema.org <http://schema.org> -- instead, multiple typing within
>>>> schema.org <http://schema.org> has been done explicitly in the
>>>> design of classes and properties rather than being relegated to
>>>> instances and reasoners.
>>>>
>>>> kc
>>>>
>>>>
>>>> On 10/7/13 5:20 PM, Aaron Bradley wrote:
>>>>
>>>> The documentation here leaves a lot to be desired. I think, at
>>>> the very
>>>> least, an example of this in use on schema.org
>>>> <http://schema.org> <http://schema.org> with
>>>> a schema.org <http://schema.org> <http://schema.org> URL would
>>>> be useful. As far as I know
>>>>
>>>> ProductModel [1] is the only type that uses additionalType in
>>>> example
>>>> code, and this very much in keeping with what the property's
>>>> description
>>>> describes as the "typical" use for the property in "adding more
>>>> specific types from external vocabularies in microdata syntax."
>>>>
>>>> Is <link> required to employ additionalType? Once an
>>>> additionalType is
>>>> declared, can properties be associated with it *and* the
>>>> initially-declared item? There's no guidance on this or any other
>>>> information on schema.org <http://schema.org>
>>>> <http://schema.org> about implementing
>>>>
>>>> additionalType.
>>>>
>>>> Note that additionalType proposal [2] included "Changes to
>>>> http://schema.org/docs/__datamodel.html
>>>> <http://schema.org/docs/datamodel.html>" - namely the insertion of a
>>>> section "Handling of Multiple Types." That section obviously
>>>> never made
>>>> its way to the Data Model page.
>>>>
>>>> [1] http://schema.org/ProductModel
>>>> [2] http://www.w3.org/wiki/__WebSchemas/__additionalTypeProposal
>>>> <http://www.w3.org/wiki/WebSchemas/additionalTypeProposal>
>>>>
>>>>
>>>>
>>>> On Mon, Oct 7, 2013 at 4:59 PM, Guha <guha@google.com
>>>> <mailto:guha@google.com>
>>>> <mailto:guha@google.com <mailto:guha@google.com>>> wrote:
>>>>
>>>> This is what http://schema.org/__additionalType
>>>> <http://schema.org/additionalType> is for.
>>>>
>>>> All of an object's types have the same standing.
>>>>
>>>> guha
>>>>
>>>>
>>>> On Mon, Oct 7, 2013 at 3:19 PM, Wes Turner
>>>> <wes.turner@gmail.com <mailto:wes.turner@gmail.com>
>>>> <mailto:wes.turner@gmail.com
>>>> <mailto:wes.turner@gmail.com>>> wrote:
>>>>
>>>> Is this what http://schema.org/__additionalType
>>>> <http://schema.org/additionalType> is for?
>>>>
>>>> --
>>>> Wes Turner
>>>>
>>>>
>>>> On Mon, Oct 7, 2013 at 3:46 PM, Aaron Bradley
>>>> <aaranged@gmail.com <mailto:aaranged@gmail.com>
>>>> <mailto:aaranged@gmail.com <mailto:aaranged@gmail.com>>> wrote:
>>>>
>>>> Dan's solution and Martin's link are excellent
>>>> ones. Just a
>>>> quick FYI a previous discussion and a proposal
>>>> related to it
>>>> provide some further information on this type of
>>>> conundrum
>>>> in schema.org <http://schema.org> <http://schema.org>:
>>>>
>>>> http://lists.w3.org/Archives/__Public/public-schemabibex/__2013Jan/0182.html
>>>> <http://lists.w3.org/Archives/Public/public-schemabibex/2013Jan/0182.html>
>>>>
>>>> http://www.w3.org/wiki/__WebSchemas/__SchemaDotOrgMetaSchema
>>>> <http://www.w3.org/wiki/WebSchemas/SchemaDotOrgMetaSchema>
>>>>
>>>> A fragment from the former reference:
>>>>
>>>> > Assuming they take OWL seriously, they would
>>>> infer new types for the
>>>> > entity if properties were mixed and matched. If
>>>> example, if the claimed
>>>> > type is schema:Book and somebody used the
>>>> schema:sku property, they
>>>> > could infer it is also a schema:Product.
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Oct 7, 2013 at 1:37 PM, Dan Scott
>>>> <dan@coffeecode.net <mailto:dan@coffeecode.net>
>>>> <mailto:dan@coffeecode.net <mailto:dan@coffeecode.net>>> wrote:
>>>>
>>>> On Mon, Oct 07, 2013 at 09:16:01PM +0100,
>>>> Chilly Bang wrote:
>>>>
>>>> Hello!
>>>>
>>>> i'm busy at the moment with marking up with
>>>> microdata of an online bookstore and
>>>> realized the
>>>> following dilemma:
>>>> if a page is about describing and selling of a
>>>> CreativeWork/Book, so i come to selling
>>>> properties
>>>> with itemprop="offers" itemscope=""
>>>> itemtype="http://schema.org/____Offer
>>>> <http://schema.org/__Offer>
>>>>
>>>> <http://schema.org/Offer>". But on this way
>>>> i can't
>>>> describe the book i sell like Product, with
>>>> product's properties - i can't find any
>>>> passage from
>>>> CreativeWork to Product. There is in fact a
>>>> passage
>>>> from Offer to Product, with
>>>> itemprop="itemOffered"
>>>> itemscope=""
>>>> itemtype="http://schema.org/____Product
>>>> <http://schema.org/__Product>
>>>>
>>>> <http://schema.org/Product>", but repeating
>>>> isn't a
>>>> good way, beside of this it isn't easy to
>>>> get such
>>>> passage into html, even with itemref.
>>>>
>>>> I see no possibility to go the way
>>>> CreativeWork->Product->Offer (or
>>>> CreativeWork->Product and
>>>> CreativeWork->Offer), but
>>>> only CreativeWork->Offer, or Product->Offer.
>>>> CreativeWork can't be a Product or am i wrong?
>>>>
>>>> Imho CreativeWork surely can own product's
>>>> properties so it must gladly have a passage
>>>> from any
>>>> CreativeWork property to Product.
>>>>
>>>>
>>>> You can just use both types in the itemtype
>>>> declaration,
>>>> for example,
>>>> itemtype="Book Product".
>>>>
>>>> We're doing this in the #schemabibex group to
>>>> express
>>>> offers for a given
>>>> item. And Martin gave a wonderful example of this
>>>> approach on this list
>>>> just a few days back at
>>>> http://lists.w3.org/Archives/____Public/public-vocabs/2013Sep/____0206.html
>>>> <http://lists.w3.org/Archives/__Public/public-vocabs/2013Sep/__0206.html>
>>>>
>>>> <http://lists.w3.org/Archives/__Public/public-vocabs/2013Sep/__0206.html
>>>> <http://lists.w3.org/Archives/Public/public-vocabs/2013Sep/0206.html>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Karen Coyle
>>>> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>>>> m: 1-510-435-8234 <tel:1-510-435-8234>
>>>> skype: kcoylenet
>>>>
>>>>
>>>
>>> --
>>> Karen Coyle
>>> kcoyle@kcoyle.net http://kcoyle.net
>>> m: 1-510-435-8234
>>> skype: kcoylenet
>>>
>>
>> --------------------------------------------------------
>> martin hepp
>> e-business & web science research group
>> universitaet der bundeswehr muenchen
>>
>> e-mail: hepp@ebusiness-unibw.org
>> phone: +49-(0)89-6004-4217
>> fax: +49-(0)89-6004-4620
>> www: http://www.unibw.de/ebusiness/ (group)
>> http://www.heppnetz.de/ (personal)
>> skype: mfhepp
>> twitter: mfhepp
>>
>> Check out GoodRelations for E-Commerce on the Web of Linked Data!
>> =================================================================
>> * Project Main Page: http://purl.org/goodrelations/
>>
>>
>>
>>
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
>
--------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen
e-mail: hepp@ebusiness-unibw.org
phone: +49-(0)89-6004-4217
fax: +49-(0)89-6004-4620
www: http://www.unibw.de/ebusiness/ (group)
http://www.heppnetz.de/ (personal)
skype: mfhepp
twitter: mfhepp
Check out GoodRelations for E-Commerce on the Web of Linked Data!
=================================================================
* Project Main Page: http://purl.org/goodrelations/
Received on Wednesday, 9 October 2013 14:54:30 UTC