- From: Souripriya Das <souripriya.das@oracle.com>
- Date: Tue, 12 Jul 2011 11:39:13 -0400
- To: RDB2RDF Working Group WG <public-rdb2rdf-wg@w3.org>
- Message-ID: <4E1C6AA1.3090808@oracle.com>
There are some issues in trying to use any well-known IRIs for these three constants: 1) rdfs:Literal is class that is a subclass of rdfs:Resource, and 2) there is no well-known IRI for blank nodes. Given this, I'd propose that we create our own special R2RML IRI constants: rr:IRI, rr:BlankNode, and rr:Literal. If we want emphasize that these are constants, we could refine these a bit (e.g., rr:IRI, rr:BLANKNODE, rr:LITERAL). Souripriya Das, 12 Jul 2011, 15:35:53 RDB2RDF Working Group Issue Tracker wrote: > ISSUE-45 (termtype-iris): IRIs instead of literals for rr:termType choices [R2RML] > > http://www.w3.org/2001/sw/rdb2rdf/track/issues/45 > > Raised by: Richard Cyganiak > On product: R2RML > > Raised by Drew Perttula: > http://lists.w3.org/Archives/Public/public-rdb2rdf-comments/2011Jun/0000.html > > > http://www.w3.org/TR/2011/WD-r2rml-20110324/#ObjectMapClass_termType_Property > currently says: > rr:termtype rdfs:range {"IRI", "BlankNode", "Literal"} . > > I was expecting those choices to be URIs themselves, not strings. http://www.w3.org/TR/rdf-schema/#ch_literal is already a well-known id for "Literal" that I think has the right meaning for this context. I'm less sure what existing URIs to use for the other two, but it seems like they ought to exist or be added to a more core spec. rdfs:Resource, maybe? > > Some reasons it would be better to use URIs than strings: > 1. The values will be able to link to their own metadata, notably documentation > 2. It's a good habit to promote. People will be copying r2rml's practices in their own RDF data. > 3. If you want, you can make up superclasses for the allowed values (something like "Term" in this case and "Reference" in the SubjectMapClass case) and potentially simplify the rr:termtype definitions. UIs for r2rml are probably making some equivalent of those superclasses (aka enums) anyway. > > > >
Received on Tuesday, 12 July 2011 15:40:35 UTC