Re: How does RDF get extended to new datatypes?

Le 30/04/2013 19:58, Pat Hayes a écrit :
>
> On Apr 26, 2013, at 2:36 AM, Antoine Zimmermann wrote:
>
>> Le 26/04/2013 00:41, Sandro Hawke a écrit :
>>> I think you're saying that in the 2004 semantics, one can't just
>>> say
>>>
>>> (a) In addition to some XSD stuff, this system also implements
>>> datatype http://example.org/daterange
>>
>> "http://example.org/daterange" is an IRI, not a datatype. So what
>> datatype does this system implements? Intuitively, this should mean
>> that it implements the datatype identified by
>> "http://example.org/daterange". But what this datatype is? It's not
>> an XSD datatype, so the standards do not say. There is no datatype
>> map given, so my RDF-2004 assumptions do not allow me to decide.
>> Still, I have my Linked-data assumptions that tell me I just have
>> to look up and figure out. All right, let's do that. This URL is
>> redirecting to http://example.iana.org/, which does not tell me
>> anything useful. So your entailment regime is incompletely
>> defined.
>
> True, in this case. But suppose we are following the 2004 spec, and
> we read some RDF which has a literal in it typed using this IRI.

If you have an RDF processor that implements an entailment regime, then 
it has a datatype map (possibly empty). If the IRI is in the datatype 
map, you know what datatype it denotes. This would not be the case if 
the D was just a set.

> All
> we have is the IRI. How do we discover what datatype map is supposed
> to be used on this datatype? The spec provides no clue as to how to
> discover this.

Exactly. Producers of RDF do not decide what entailment regimes have to 
be used by consumers. It's up to the application that consumes RDF to 
decide what regime to use, and that includes what datatype map to use. 
In any case, the RDF processor must know to what datatype the IRI *maps*.

  And what does it even *mean*? It means simply that we
> need to know what datatype this IRI is supposed to... well, to
> denote, in fact.  That is, we have an IRI and we need to know what it
> is being used to denote, to refer to.

It is allowed to use any IRI as a datatype IRI in a literal. It is not 
required that all applications know what all datatype IRIs denote. We do 
not "need" anything particular.


> That is exactly what the 2013
> wording assumes: there is an IRI which evidently is being used to
> identify a datatype, and we are supposed to find out which datatype
> it refers to.

We are not "supposed to find out". We must know, because the definitions 
use the L2V mapping of the datatype the IRI denotes. So the application 
must define to what datatype the IRI maps to, in any case, whether 
2004-wording or 2013-wording is assumed.

> (How to find out, is not specified: perhaps by using
> linked data principles, perhaps just by being inside the relevant
> user community.) But phrasing this as "finding out which datatype map
> it is being used with" doesn't add anything useful to the
> discussion.
>
> But, one might respond, what of the case (purely imaginary, but
> possible) in which the same IRI is used by one source to indicate one
> datatype, and by a different source to indicate a different datatype?

What does it mean that a source is indicating a datatype? Using an IRI 
in the place of a datatype IRI does not indicate anything about the 
datatype map (or datatype set) used by the entailment regime.

> I guess this could conceivably happen, but it could have happened in
> 2004 as well, and then it would have been described as two sources
> using different datatype maps. But again, adding "datatype map" to
> the discussion does not change or improve the situation, or provide
> any clarification about how to proceed; it simply describes the same
> situation in more complicated language. (Worse, in fact, the 2004
> wording seems to suggest that this situation is acceptable, when in
> fact it is not, and should be strongly deprecated, although I confess
> I am having trouble finding a form of words to say this.)

What is problematic or complicated about D-entailment is not at all 
whether D is a partial mapping or a set. Partial mappings are not 
complicated. The difficulty is that it allows an entailment regime to be 
customised, and therefore, that the constraints imposed by the 
customisation are not normatively defined anywhere. This makes it 
difficult to tell how one can conform to the standard on D-entailment, 
because it's actually up to the application to decide. And making D a 
set does not help in this respect.

Thinking about it, and seeing your proposal to solve the issue, I'd like 
that there is a more general notion of customised entailment regime, 
where one can impose constraints on IRI interpretations beyond simply 
making it denote a fixed datatype.

Anyway, at this point I'm not going to fight and will accept 
(reluctantly) the proposed wording and let the commenters in LC decide.

AZ.

>
> Pat
>
>>
>>>

[snip]

-- 
Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
http://zimmer.aprilfoolsreview.com/

Received on Friday, 3 May 2013 17:58:47 UTC