Re: Schema.org in RDF ... expected Types in RDFS

Thanks Martin.
I appreciate your views - in fact I was hoping you would help me put the thing in context, as this is clearly your world (no irony intended).

I didn't think we were hopping on schema.org
I thought what had happened was another way of publishing metadata had come along, and we (at least in the bit of the discussion I was involved) were discussing how we can facilitate good interaction, rather than Linked Data sitting in a silo.
This happens all the time.

Having a sort of "agreed" way of projecting schema.org into the Linked Data world is a pre-requisite for being able to deploy our Linked Data goodness over it. This would include being able to do alignment with GoodRelations and other relevant schemas, ontologies and instances.
If we don't then it will end up with lots of people doing it independently in any case, as they try to consume it themselves for their own RDF stores.

Of course, I see your points about schema.org being in danger of causing a net loss of structured data (I would say that I am disappointed, to put it mildly) - but if people do end up using it, we (LInked Data Community) should have a way of consuming the little they do publish.

So, for my bit of this, we can get a bit of agreement about how to interact with it, and then move on, watching to see if it gets more interesting.

Best
Hugh

On 6 Jun 2011, at 11:30, Martin Hepp wrote:

>> As the three major seach
>> engines agree on it, it will become a de-facto standard regardless to
>> wether we like it or not.
>
>
> Hi,
> do not understand why you all hop on schema.org.
>
> It is absolutely unclear whether schema.org will make it, for the simple reasons that:
>
> 1. The schema.org syntax for products is basically the same as the Google Microdata syntax proposed in November 2011. Of all three options (hProduct/hListing, GoodRelations in RDFa, Microdata), this was, afaik, the least popular.
>
> Now, with Google having a market-share of > 80 % in most countries, if people do not add this to their pages when Google recommends it, why should Yahoo and Bing joining make a difference? Most sites are optimized for Google when in doubt.
>
> 2. On the very same page on which Bing is announcing their rich snippets support, they state that they will add GoodRelations in RDFa to the crawler.
>
> 3. The main bottleneck for the a bit slow adoption of rich meta-data for sites is
>
> - the ridiculously slow process of whitelisting your site for rich snippets (it can take months for your page to show actual rich snippets) and
> - the fact that they are only unofficially accepting RDFa in snippet-style [1, 2], which makes authoring RDFa patterns and developing shop extensions a lot easier, because it separates the organization of visible content from the data structures.
>
> Note: Not every move by the three giants will be a success. I guess that only 50 % of e-commerce sites support e.g. sitemaps.org. Google Wave was also a big hype but is now dead, and the list of other failures is long.
>
> I really don't get why you are not fighting for an open Web. Schema.org will not reduce the entrance barriers to rich markup significantly.
> RDFa, in particular in 1.1 flavor, is a great, extensible technique, with tooling etc.
>
> Best
> Martin
>
> [1] Hepp, Martin; García, Roberto; Radinger, Andreas: RDF2RDFa: Turning RDF into Snippets for Copy-and-Paste, Technical Report TR-2009-01, 2009, PDF at http://www.heppnetz.de/files/RDF2RDFa-TR.pdf
> [2] http://www.ebusiness-unibw.org/wiki/RDFaAuthoring#RDFa_in_Snippet_Style
>
>
> On Jun 6, 2011, at 10:59 AM, Thomas Bandholtz wrote:
>
>> For me, schema.org is just another schema. As the three major seach
>> engines agree on it, it will become a de-facto standard regardless to
>> wether we like it or not.
>>
>> Obviously, they decided not to re-use anything as they are sure enough
>> they will be re-used instead.
>>
>> What you bring up is called polymorphy in the OO world: Any instance may
>> be instance of multiple classes. I have a case where the domain experts
>> are talking about a thesaurus, so everthing is a skos:Concept.
>>
>> But they have also place names and events.
>> So far, each place name is label of a skos:Concept. But we also have the
>> more specific Geonames Ontology, so the place name is as well
>> gn:officialName which implies that the same instance now has also type
>> gn:Feature (which is subclass of wgs84:SpatialThing, so the instance is
>> as well a wgs84:SpatialThing).
>>
>> Now we have one more player in the open schema world:
>> the same instance will now become a schema:Place instance as well.
>> So what?
>>
>> As far as these schemas are not inconsistent with one another, there is
>> absolutely no problem. If there are some contradictions, the reasoner
>> will hopefully detect them and give us a chance to align the schemas
>> with a good reason.
>>
>> What is the "purpose" of such multiple class assignment?
>>
>> Any agent searching the LOD cloud for skos:Concept instances will find
>> my instance, and the same applies to those agents searching for
>> gn:Feature or schema:Place instances.
>>
>> If your instance is not found, you may as well delete it ;-)
>>
>> I used to dream about schema alignment and re-use for decades, but I
>> have come to the conclusion: schema diversity is just like
>> bio-diversity. We do not have to overcome it, it is a protected asset!
>>
>> Best regards,
>> Thomas
>>
>> Am 05.06.2011 13:28, schrieb Hugh Glaser:
>>> Interesting question.
>>> As an an engineer, I was trying to work out if the schema was fit for purpose.
>>> Of course, I was assuming that we agreed on what the purpose was, but that was a mistake, as it usually is.
>>>
>>> I thought that the purpose was that I would have a schema I could then use in my RDF, that would have a simple correspondence with schemas.org (so I stood a chance of moving between them), while enabling me to do my Linked Data goodness (importantly conforming to the first principle).
>>> In particular, I did not think that we were trying to capture the exact meaning of what they (Schema.org) say.
>>>
>>> So my fit for purpose would have (at least):
>>> 1) Will the resultant RDF be useable as Linked Data?
>>> 2) Can I move between the two notations without loss of (important) information?
>>>
>>> The following from Schema.org seems very relevant in the second of these
>>> "Conformance
>>> While we would like all the markup we get to follow the schema, in practice, we expect a lot of data that does not. We expect schema.org properties to be used with new types. We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string. In the spirit of "some data is better than none", we will accept this markup and do the best we can."
>>>
>>> So what can the RDFS respond to this, with particular reference to (my) purpose (2)?
>>> As always we must ask what is the role of the schema.
>>> It clearly can't be to police an acceptance of valid RDF documents that have come from Schema.org - it would reject many things that will become acceptable to Schema.org.
>>> It clearly can't be to police the publication of RDF documents on their way to Schema.org - it would restrict too much.
>>> It may be useful to provide inference in a RDF store with schema.rdfs.org RDF in it.
>>>
>>> Essentially, it means not only dropping all the range restrictions, but even the domains as well, if it is to be fit for (my) purpose (2).
>>> But it then becomes less useful for (my) purpose (1).
>>> Indicating useful restrictions is a good thing to do, to help me get my RDF right, and help me work out what is in a schema.rdfs.org RDF store, and even give me more useful inference in the store.
>>> It is just that such use directly conflicts with being useful as a bridge with Schemas.org.
>>>
>>> How to square the circle?
>>> To be useful for the future development of Schemas.org, the more I look the more I think just dropping all domain and range is the only way forward (does that go too far for you, Pat? :-) )
>>> However, the schema.rdfs.org does tell me a lot of useful stuff with the restrictions - is it really the case that more than one description is useful? That would be horrible or would it?
>>>
>>> I suspect that I may need to don a flameproof suit here, as I tread into well worn paths of knowledge acquisition, but never mind, it's Sunday morning and raining outside :-)
>>>
>>> Best
>>> Hugh
>>>
>>> On 5 Jun 2011, at 07:37, Thomas Bandholtz wrote:
>>>
>>>> Am 04.06.2011 17:35, schrieb Pat Hayes:
>>>>> Far as I can see, one could simply delete every range-string triple. Nothing would break in the RDFS by doing this, and AFIKS nothing is gained from having these range assertions.
>>>> Deleting every range assertion would not express what they want to say:
>>>> "many properties have 'expected types'. This means that the value of the
>>>> property can itself be an embedded item ... But this is not a
>>>> requirement—it's fine to include just regular
>>>> text or a URL." [1]
>>>>
>>>> They do not expect just anything, but a certain type or a literal
>>>> (denoting an "informal" instance of this type).
>>>>
>>>> Sounds like
>>>> schema:someProperty rdfs:range [ owl:unionOf (schema:Thing rdfs:Literal ) ];
>>>>
>>>> What funny kind of OWL flavor or profile might this be?
>>>> Note that they do not use owl:ObjectProperty nor owl:DatatypeProperty
>>>> but simply rdf:Property, so it might be just fine. Good old RDFS!
>>>>
>>>> Some comments from the OWL police?
>>>>
>>>> Thomas
>>>>
>>>>
>>>> [1] http://schema.org/docs/gs.html#schemaorg_expected
>>>>
>>>>
>>>>> Pat
>>>>>
>>>>> On Jun 4, 2011, at 4:39 AM, Hugh Glaser wrote:
>>>>>
>>>>>> Sure does rock.
>>>>>> As you know, I never venture into ontology definition, to avoid displaying my ignorance, but now and then... :-)
>>>>>> Suggestion:
>>>>>>
>>>>>> The RDFS will (I think!) perpetuate the classic problem (being a natural translation), in that there are lots of range strings.
>>>>>> For example:
>>>>>> schema:currenciesAccepted a rdf:Property;
>>>>>> rdfs:label "Currencies Accepted"@en;
>>>>>> rdfs:comment "The currency accepted (in ISO 4217 currency format)."@en;
>>>>>> rdfs:domain schema:LocalBusiness;
>>>>>> rdfs:range xsd:string;
>>>>>> rdfs:isDefinedBy <http://schema.org/currenciesAccepted>;
>>>>>> .
>>>>>> and
>>>>>> schema:headline a rdf:Property;
>>>>>> rdfs:label "Headline"@en;
>>>>>> rdfs:comment "Headline of the article"@en;
>>>>>> rdfs:domain schema:CreativeWork;
>>>>>> rdfs:range xsd:string;
>>>>>> rdfs:isDefinedBy <http://schema.org/headline>;
>>>>>> .
>>>>>> And even productID
>>>>>>
>>>>>> I count 53  "rdfs:range xsd:string" and 8 "rdfs:range [ owl:unionOf (xsd:decimal xsd:string) ]" of this kind.
>>>>>>
>>>>>> As I say, I think that means that to conform, I can't have a Resource as Range.
>>>>>> So it is institutionalising a Bad Thing, simply because schema.org says that, for example, "productID" is "text".
>>>>>>
>>>>>> Of course, people who use http://schema.rdfs.org/ probably will use Resources for places, currencies, etc, (as they should) so maybe the RDFS needs to reflect this?
>>>>>>
>>>>>> Won't try and suggest...
>>>>>>
>>>>>> Best
>>>>>> Hugh
>>>>>>
>>>>>> On 3 Jun 2011, at 22:06, Michael Hausenblas wrote:
>>>>>>
>>>>>>> http://schema.rdfs.org
>>>>>>>
>>>>>>> ... is now available - we're sorry for the delay ;)
>>>>>>>
>>>>>>> Cheers,
>>>>>>>         Michael
>>>>>>> --
>>>>>>> Dr. Michael Hausenblas, Research Fellow
>>>>>>> LiDRC - Linked Data Research Centre
>>>>>>> DERI - Digital Enterprise Research Institute
>>>>>>> NUIG - National University of Ireland, Galway
>>>>>>> Ireland, Europe
>>>>>>> Tel. +353 91 495730
>>>>>>> http://linkeddata.deri.ie/
>>>>>>> http://sw-app.org/about.html
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Hugh Glaser,
>>>>>>           Intelligence, Agents, Multimedia
>>>>>>           School of Electronics and Computer Science,
>>>>>>           University of Southampton,
>>>>>>           Southampton SO17 1BJ
>>>>>> Work: +44 23 8059 3670, Fax: +44 23 8059 3045
>>>>>> Mobile: +44 75 9533 4155 , Home: +44 23 8061 5652
>>>>>> http://www.ecs.soton.ac.uk/~hg/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ------------------------------------------------------------
>>>>> IHMC                                     (850)434 8903 or (650)494 3973
>>>>> 40 South Alcaniz St.           (850)202 4416   office
>>>>> Pensacola                            (850)202 4440   fax
>>>>> FL 32502                              (850)291 0667   mobile
>>>>> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Thomas Bandholtz
>>>> Principal Consultant
>>>> innoQ Deutschland GmbH
>>>> Halskestr. 17
>>>> D-40880 Ratingen, Germany
>>>>
>>>> Mail:      thomas.bandholtz@innoq.com
>>>> Mobile:    +49 178 4049387
>>>> Phone:     +49 228 9288490
>>>> Fax:       +49 228 9288491
>>>>
>>>> http://www.innoq.com/de/themen/linked-data
>>>>
>>>>
>>>>
>>
>>
>> --
>> Thomas Bandholtz
>> Principal Consultant
>> innoQ Deutschland GmbH
>> Halskestr. 17
>> D-40880 Ratingen, Germany
>>
>> Mail:        thomas.bandholtz@innoq.com
>> Mobile:      +49 178 4049387
>> Phone:       +49 228 9288490
>> Fax: +49 228 9288491
>>
>> http://www.innoq.com/de/themen/linked-data
>>
>>
>>
>

--
Hugh Glaser,
              Intelligence, Agents, Multimedia
              School of Electronics and Computer Science,
              University of Southampton,
              Southampton SO17 1BJ
Work: +44 23 8059 3670, Fax: +44 23 8059 3045
Mobile: +44 75 9533 4155 , Home: +44 23 8061 5652
http://www.ecs.soton.ac.uk/~hg/

Received on Monday, 6 June 2011 11:46:29 UTC