Hey
Am 10.03.2016 um 00:49 schrieb James Heald:
On 09/03/2016 23:09, Stas Malyshev wrote:
> Hi!
>
>> Technically, the main purpose of having a separate datatype was to
>> explicity
>> model values that identify a resource (in the RDF sense, where
>> resource means
>> "anything that can be identified unambiguously"), so we can apply
>> mappings (e.g.
>> to URIs and URLs) when exporting and displaying them.
>
> We need also to be careful here as we have some external ID-like types
> that do not translate to URIs. So we should either not convert them to
> that type, or we'd have complex logic of which type the corresponding
> properties should be (since we should tell whether this property uses
> string or URI, and we should be able to do it automatically when
> generating RDF).
>
> Right now I'd suggest not converting such properties, unless there's a
> good reason to.
>
In theory, having an identifier datatype and rendering strings as urls
are two separate things. We could dispatch the rendering based on
property_info and support the "formatter url" property for more values
(eg. coordinates) without even having an identifier datatype. It is just
a good idea to conceptually separate external identifiers from other
string values.
I don't see why it is an issue that some external identifiers don't
translate to URIs. What complex logic is involved here? In RDF we should
just add the plain identifier like we have it now as the default value,
and the expanded urls as derived values if available.
Somewhat related to what Stas writes, can I remind again that we have
many properties that have single identifiers, that map to different URLs
for different purposes (eg a URL for human readers, a slightly different
URL for RDF).
Both of those URLs should be available /somewhere/ in the triplestore or
the RDF dump -- but probably neither of them are what one would want the
simple wdt: form of the property on SPARQL to return.
I agree that for the simple wdt: form we should still have the plain id
without any expanded urls. For the derived values (full urls but also
relevant for other data types), we still need to find a proper way to
represent those derived data values in our data model. As soon as we
tackle that issue, it will be possible to provide those urls in the api
output as well as the serialized RDF.
Best regards
Bene