- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 06 Jun 2011 10:39:43 +0100
- To: public-lod@w3.org
On 6/6/11 9: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! Yep ++ KIngsley > 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 >>> >>> >>> > -- Regards, Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
Received on Monday, 6 June 2011 09:40:09 UTC