Re: Proposal to extend rangeIncludes of DataTypes predicates in schema.org

Hi Martin,
Yes, it can also help if the sponsors of schema.org declare that they 
accept XSD-datatype-typed RDF literals in addition to plain string literal 
so the publisher can use XSD datatypes for typed literals in RDFa without 
the need to change schema.org.
However this is not 'yet' done so far  and looking at some examples given 
in git repo (
https://github.com/rvguha/schemaorg/blob/master/data/examples.txt), it 
shows that only plein-literal are accepted. That was the rationale of the 
proposal.
One of other approach can help to solve the problem.

Kind Regards,

Marc Twagirumukiza | Agfa HealthCare
Senior Clinical Researcher | HE/Advanced Clinical Applications Research
T  +32 3444 8188 | M  +32 499 713 300

http://www.agfahealthcare.com
http://blog.agfahealthcare.com
Click on link to read important disclaimer: 
http://www.agfahealthcare.com/maildisclaimer 



From:   "martin.hepp@ebusiness-unibw.org" 
<martin.hepp@ebusiness-unibw.org>
To:     Marc Twagirumukiza/AXPZC/AGFA@AGFA
Cc:     W3C Web Schemas Task Force <public-vocabs@w3.org>
Date:   10/11/2014 10:53
Subject:        Re: Proposal to extend rangeIncludes of DataTypes 
predicates in schema.org



While this is an interesting direction, I think this would rather increase 
confusion - most schema.org datatypes have very close XSD counterparts, 
and an RDF-based consuming client could easily use heuristics to map from 
a schema.org datatype to an XSD datatype. 

Listing e.g. xsd:int and xsd:integer in parallel to schema.org:Number 
would make the human-readable display of schema.org more confusing.

It was a design decision of schema.org back then to use a self-contained 
meta-model, with datatypes and ontology language components (like 
rangeIncludes, sameAs, Class, Property,...) being defined locally inside 
schema.org. There are pros and cons for this approach, but in any case it 
is the established base.

Also, I think it would be sufficient if the sponsors of schema.org declare 
that they accept XSD-datatype-typed RDF literals in addition to plain 
string literals.

Then a publisher can use XSD datatypes for typed literals in RDFa without 
the need to change schema.org.

Martin


On 10 Nov 2014, at 10:08, Marc Twagirumukiza <marc.twagirumukiza@agfa.com> 
wrote:

> Hello there, 
> I would like to open discussions about the proposal of extending all 
dataTypes predicates ranges by their corresponding XSD classes. 
> This will keep 'somehow' the semantic use of the dataType predicates of 
schema.org. 
> 
> Most concerned properties are: 
> -birthdate:  http://schema.org/birthDate 
> -startDate:  http://schema.org/startDate 
> -endDate:  http://schema.org/endDate 
> 
> (I understand that other dataTypes properties' ranges may needs to be 
harmonised as well,  but this can be done upon specific need). 
> 
> Also for 
> -value:  http://schema.org/value 
> 
> Eg. For birthDate: 
> 
> <div typeof="rdf:Property" resource="http://schema.org/birthDate">  
>      <span class="h" property="rdfs:label">birthDate</span> 
>      <span property="rdfs:comment">Date of birth.</span> 
>      <span>Domain: <a property="http://schema.org/domainIncludes" href="
http://schema.org/Person">Person</a></span> 
>      <span>Range: <a property="http://schema.org/rangeIncludes" href="
http://schema.org/Date">Date</a></span> 
>   + <span>Range: <a property="http://schema.org/rangeIncludes" href="
http://www.w3.org/2001/XMLSchema#date">xsd:Date</a></span> 
> </div> 
> 
> I would like having your thoughts on this, before I can send the 
proposal in Git repo. 
> 
> Kind Regards,
> 
> Marc Twagirumukiza | Agfa HealthCare
> Senior Clinical Researcher | HE/Advanced Clinical Applications Research
> T  +32 3444 8188 | M  +32 499 713 300
> 
> http://www.agfahealthcare.com
> http://blog.agfahealthcare.com
> Click on link to read important disclaimer: 
http://www.agfahealthcare.com/maildisclaimer 
> 
> Message Recall Request
> Request date:          10/11/2014 
> Message Recalled:              Link
> No report requested 
> 

Received on Monday, 10 November 2014 10:02:47 UTC