Re: Schema.org in RDF ...

On 13 Jun 2011, at 00:20, Pat Hayes wrote:
>>>>> What do we say when the range of a property is supposed to be, say, people, but its considered OK to insert a string to stand in place of the person?
>>>> 
>>>> Well, I can define a class that contains both people (in the foaf:Person sense) and names of people (that is, string literals).
>>> 
>>> Of course. But you didn't, did you? You (that is, Schema.org) said that the range of the property was one of these and NOT the other. Which is what I was complaining about.
>> 
>> Where is it said that the range is one and not the other?
> 
> Well, if you say the range is xsd:string, then anything which is a value has to be a string, right? As for example (taken at random)
> 
> schema:cookingMethod a rdf:Property;
>    rdfs:label "Cooking Method"@en;
>    rdfs:comment "The method of cooking, such as Frying, Steaming, ..."@en;
>    rdfs:domain schema:Recipe;
>    rdfs:range xsd:string;
>    rdfs:isDefinedBy <http://schema.org/Recipe>;
> 
> This says that the range is xsd:string, so nothing other than an xsd string will be acceptable here.
> 
> Am I missing something? 

You keep switching topics.

Read the conversation quoted above. You talked about properties where the range is supposed to be people, but you want to use a string. I said: No problem, we didn't say that schema:Person is disjoint from strings.

Now you're talking about properties where the range is supposed to be strings, but you want to use ... people? That's a different case.

The reason why we're having this conversation is this interesting quote from [1]:

>> “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.”

This is about the first case (string instead of thing) and not about the second (thing instead of string).

The first case is immensely important, because publishers may have insufficient data or motivation to provide a structured value (e.g., schema:Person with its various properties), and therefore have to choose between just providing a simple string value (e.g., the person's name) or not using the property at all.

The second case is of much less immediate concern. It occurs when some data publisher is not content with simply providing a string value that Google understands, but wants to provide a complex description with more detail than the schema.org terms provide. The answer to that is, keep using the schema.org property with a simple string value, and define an extension to the vocabulary.

Best,
Richard

[1] http://schema.org/docs/datamodel.html

Received on Monday, 13 June 2011 07:33:56 UTC