Expansion of prefixes within URI templates

[JeniT]

It would be quite useful to be able to do:

"propertyUrl": "schema:name"

Given that propertyUrl is a URI template, the way to make this work would be to expand the prefix either before or after its expansion as a URI template. I suggest after.

[iherman]

I am lukewarm about this... But, in any case, this should be required to work only for predefined prefixes, right?

Ivan

On 04 Feb 2015, at 15:00 , Jeni Tennison notifications@github.com wrote:

It would be quite useful to be able to do:

"propertyUrl": "schema:name"

Given that propertyUrl is a URI template, the way to make this work would be to expand the prefix either before or after its expansion as a URI template. I suggest after.

—
Reply to this email directly or view it on GitHub.

---

Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

[gkellogg]

Yes, I think we should be sure that template values are expanded first. I think it needs to be done when transforming into a Template used by the template processor, and before joining to the metadata base URL. I'll take the action of adding such text.

[iherman]

Let me try to define a bit more precisely what this would mean in practice

1. Use the RFC to expand the template. Note that the template does not mean that the result of the expansion is an absolute URL.
2. Check if the the expansion is of the form prefix:something. If so then:
   1. see if the value of prefix is on the list of the predefined prefixes defined though the RDFa initial context. If so, the expansion is in fact a CURIE and should be treated accordingly.
   2. otherwise, the expansion is a general URI, i.e., can be an absolute URL with http, or can be a urn, or anything; in RDF, this is used as a URIReference
3. Otherwise, the expansion is a relative URL that has to be made absolute with @base and the treated accordingly

Is that fine? It works for me...

[gkellogg]

One of the consequences of merging multiple metadata files is that information should be maintained relative to the file in which it is defined. For title, this means that the @language of the metadata file it is originally defined in should be maintained. For Link properties, I believe this means that the links should be resolved relative to the URL base of the metadata file it's defined in. It's hard to see how this wouldn't be true for URI Template properties as well, which means, to me, that a URL template property would need to be resolved against it's original base URL. This seems to be inconsistent with doing prefix expansion.

@iherman's statement presumes that such properties are not first resolved against the in-effect base URL, but that this is deferred until the URL is expanded. So, if aboutUrl were defined in one metadata file and propertyUrl, they would resolve against the same thing, either the first metadata file to define @base, or the base of the first metadata file to be merged IIRC.

[iherman]

On 09 Feb 2015, at 23:03 , Gregg Kellogg notifications@github.com wrote:

One of the consequences of merging multiple metadata files is that information should be maintained relative to the file in which it is defined. For title, this means that the @language of the metadata file it is originally defined in should be maintained. For Link properties, I believe this means that the links should be resolved relative to the URL base of the metadata file it's defined in. It's hard to see how this wouldn't be true for URI Template properties as well, which means, to me, that a URL template property would need to be resolved against it's original base URL. This seems to be inconsistent with doing prefix expansion.

:-( :-( This whole thing becomes more and more complicated, I am really beginning to be concerned about the complexity of what we are building here.

In my view @base should follow the priority that we have established for metadata. This means that @base, say, defined in the user metadata should override the metadata files. That makes things way simpler and it is simply a matter of properly defining things. Users can then easily adapt; after all, they can use absolute uri-s, @base is only a matter of convenience.

(I think the way we define language and use @language already takes care of that for language tags)

Ivan

@iherman's statement presumes that such properties are not first resolved against the in-effect base URL, but that this is deferred until the URL is expanded. So, if aboutUrl were defined in one metadata file and propertyUrl, they would resolve against the same thing, either the first metadata file to define @base, or the base of the first metadata file to be merged IIRC.

—
Reply to this email directly or view it on GitHub.

---

Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

[gkellogg]

:-( :-( This whole thing becomes more and more complicated, I am really beginning to be concerned about the complexity of what we are building here.

I'm sympathetic, and it is indeed getting complex :(

In my view @base should follow the priority that we have established for metadata. This means that @base, say, defined in the user metadata should override the metadata files. That makes things way simpler and it is simply a matter of properly defining things. Users can then easily adapt; after all, they can use absolute uri-s, @base is only a matter of convenience.

I believe we said elsewhere that information defined in a metadata file would be localized to that file. Certainly, a title needs to take the @language from the file in which it is located, doing the same with base URL with, or without @base being explicitly defined, is consistent with that. The main thing is that we be consistent, since anything else will only lead to more problems.

From a JSON-LD view, it depends on how we treat a URI Template property; if it is to be treated as a URI (which, at least for propertyUrl, it probably is mostly), then it would be defined as having "@type": "@id", which from an RDF processing perspective would have it expand to the base of the file it's defined in. We stretch this a fair amount when we describe merging without regard to the JSON-LD semantics. if a URI Template property represents a resource (which it ultimately does), then it is consistent to think of this as such, but that is complicated if we want to consider the value after template expansion to be a PName/Compact IRI.

Note that if something like propertyUrl were defined as "schema:{_name}", then it would expand to "http://schema.org/{_name}", which would typically have the desired effect, if say, the column name were "name" or "description".

[iherman]

On 10 Feb 2015, at 10:21 , Gregg Kellogg notifications@github.com wrote:

:-( :-( This whole thing becomes more and more complicated, I am really beginning to be concerned about the complexity of what we are building here.

I'm sympathetic, and it is indeed getting complex :(

And that may have consequences. W3C specifications, and therefore their implementations, often get very (too) complex, this is an issue we are facing with the community. I am genuinely concerned of getting to the same problem here, and users as well as implementers will become really messed up.

In my view @base should follow the priority that we have established for metadata. This means that @base, say, defined in the user metadata should override the metadata files. That makes things way simpler and it is simply a matter of properly defining things. Users can then easily adapt; after all, they can use absolute uri-s, @base is only a matter of convenience.

I believe we said elsewhere that information defined in a metadata file would be localized to that file.

I do not know whether we say that, but I am not sure we should make such an overall statements.

Certainly, a title needs to take the @language from the file in which it is located,

Correct

doing the same with base URL with, or without @base being explicitly defined, is consistent with that.

I am not sure of this. Why would that be necessarily the case, except for consistency? See also my comment below...

The main thing is that we be consistent, since anything else will only lead to more problems.

From a JSON-LD view, it depends on how we treat a URI Template property; if it is to be treated as a URI (which, at least for propertyUrl, it probably is mostly), then it would be defined as having "@type": "@id", which from an RDF processing perspective would have it expand to the base of the file it's defined in. We stretch this a fair amount when we describe merging without regard to the JSON-LD semantics. if a URI Template property represents a resource (which it ultimately does), then it is consistent to think of this as such, but that is complicated if we want to consider the value after template expansion to be a PName/Compact IRI.

I think we should be careful with the way we look at JSON-LD. I believe the relationship between the CSV metadata and JSON-LD (or RDF) should be defined saying that the final (ie, merged) metadata is JSON-LD compatible and interpretable, but not (necessarily) the constituents. In general, it is the final metadata that really counts, and the constituents could be considered as #include files, so to say...

And, unfortunately I would say, I think that, from a JSON-LD point of view, the templates are no URI-s. They are strings and should be treated so in the JSON-LD @context. That is the only consistent interpretation in my view...

Note that if something like propertyUrl were defined as "schema:{_name}", then it would expand to "http://schema.org/{_name}", which would typically have the desired effect, if say, the column name were "name" or "description".

I do not understand that. In my mental model,

"schema:{_name}" would expand to "schema:description" as far as the template expansion goes, and that would be expanded, by virtue of the default prefixes, to "http://schema.org/description". I am not sure how this relates to the issue of @base

Ivan

—
Reply to this email directly or view it on GitHub.

---

Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

[gkellogg]

We should definitely set aside time at th F2F to address complexity and see if we might readdress some of iur assumptions to make things simpler.

Regarding URI Template properties we should follow the dictum of least surprise. That may very well mean treating such properties as liiterals

[iherman]

On 10 Feb 2015, at 11:21 , Gregg Kellogg notifications@github.com wrote:

We should definitely set aside time at th F2F to address complexity and see if we might readdress some of iur assumptions to make things simpler.

Huge +1!

Ivan

Regarding URI Template properties we should follow the dictum of least surprise. That may very well mean treating such properties as liiterals

—
Reply to this email directly or view it on GitHub.

---

Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

[JeniT]

Resolved at Feb F2F. The order of processing is as described in #191 (comment). These properties are string properties, the URL template is expanded first. Any resolution (ie expanding prefixes & resolving against a base URL) is done after that expansion. Editor action to make this so.