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

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