Open rjyounes opened 2 months ago
Your interpretation was not my intention for the addresses model. The URL (not URI) associated with an electronic address should be captured as a string. I think gist:containedText is fine the way it is.
this raises a more general question: When to use anyuri. It seems like the right thing to do some of the time, but it is not clear what the practical benefits are in actual applications, vs. using xsd:string
@DanCarey404:
Your interpretation was not my intention for the addresses model. The URL (not URI) associated with an electronic address should be captured as a string. I think gist:containedText is fine the way it is.
Why not use a URL typed as xsd:anyURI
? E.g., to make an actionable link in a browser.
The proposal is not to change gist:containedText
- apologies, I think the original version of this issue did perhaps propose that - but to use a new predicate in the extension ontology with xsd:anyURI
values.
@uscholdm:
this raises a more general question: When to use anyuri. It seems like the right thing to do some of the time, but it is not clear what the practical benefits are in actual applications, vs. using xsd:string
See above - for a web application consuming the RDF to make this an actionable link rather than text without having to look at, say, the ElectronicAddressType
. xsd:anyURI
is completely ontology-agnostic.
According to the gist 13 address model, URLs can be modeled as instances of
gist:Address
with thecontainedText
the URL string. We want to datatype these asxsd:anyURI
, but the range ofcontainedText
isxsd:string
.I think the recommendation to users is to define their own property, such as
ex:url
, to use in such cases, in the same way that we have suggested they could defineaddressCity
, etc.