- From: Marc Twagirumukiza <marc.twagirumukiza@agfa.com>
- Date: Mon, 10 Nov 2014 11:44:52 +0100
- To: martin.hepp@ebusiness-unibw.org
- Cc: W3C Web Schemas Task Force <public-vocabs@w3.org>
- Message-ID: <OF87614F05.0CF2173B-ONC1257D8C.003A2484-C1257D8C.003B0A71@agfa.com>
I agree, RDF-based consumers of data can fix the data by adding datatype information from the vocabulary to literals (e.g. with a SPARQL CONSTRUCT rule). This approach has been used for a while but semantically saying it has many limitations. The best approach -I am convinced is to extend rangeIcludes objects. I would suggest not adding them systematically (only where needed) on the predicates like birthDate, startDate, endDate. This will not be a problem for other consumers will continue to use the traditional way. The other approache my help as well: the sponsors of schema.org declare that they accept XSD-datatype-typed RDF literals in addition to plain string literals. Kind Regards, Marc 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 11:13 Subject: Re: Proposal to extend rangeIncludes of DataTypes predicates in schema.org Yes, but on the other hand, the RDF approach of forcing to have datatype information at the level of each individual literal is IMO flawed. It can be explained from the history of RDF, with the need to work with data that has no vocabulary (then you need to know the datatype from the literal). So I am not convinced that it is really worthwile to go that road. Rather, RDF-based consumers of data should fix the data by adding datatype information from the vocabulary to literals (e.g. with a SPARQL CONSTRUCT rule). The only use-case where I see a need for datatype information attached to literal values is when the vocabulary allows multiple datatypes that the client could not distinguish automatiocally (e.g. think of a property that allows a xsd:string and xsd:boolean - then "True" may be a string or a boolean value). But that is a rare exception. Martin On 10 Nov 2014, at 11:02, Marc Twagirumukiza <marc.twagirumukiza@agfa.com> wrote: > 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:45:18 UTC