Allow terms to expand to multiple IRIs

[linclark]

Many publishers need to publish in multiple vocabularies so that they can target multiple consumers. The only way that I can see to use multiple vocabularies is to repeat the value, using a different term as the attribute each time.

I would like to see a more concise way to use multiple vocabs.

For example:

"@context": {
  ...
  "name": ["schema:name", "foaf:name"]
},
"name": "Lin Clark"

_:t0 <http://schema.org/name> "Lin Clark" .
_:t0 <http://xmlns.com/foaf/0.1/name> "Lin Clark" .

In Drupal 8, the current thinking is that we would have a site specific vocabulary automatically generated for each site. However, we also need to allow the user to map to external vocabularies as needed; for example, Schema.org.

If we can only use multiple vocabularies by repeating the values multiple times, I fear it would be too verbose for our use case.

[scor]

Indeed, I was asking about this also on IRC a few days ago but it seems like it's not supported (yet). In a way this is similar to property="schema:name foaf:name" in RDFa.

[lanthaler]

An alternative would be content negotiation or having different URLs for documents expressed with different vocabularies. I proposed (last paragraph of that comment) to use a profile media type parameter for such scenarios some time ago.

[linclark]

Thanks for the suggestion.

I have not seen that pattern (conneg based on which predicates the consumer wants) used before in Linked Data and I agree with Gregg Kellog's sentiment that it isn't something I'm ready to accept. Even if I were on board, I wouldn't feel comfortable relying on such a novel pattern in Drupal core without seeing it used in the wild by others.

[retog]

I'm skeptical about optimizing the format to deliver a highly redundant set of triples to increase chances that a client understands it. All the client I've been working on would just store all the triples, this would be quite a mess.

I think the situation is different with rdfa where the same html part might be the value of properties with distinct meanings (say "author" and "copyRightsHolder").

Instead of the additional syntax one can express this with owl:sameAs relationships on a semantic level.

[linclark]

The tools we're targeting don't do reasoning, so relying on owl:sameAs would make it a no go for us.

[lanthaler]

RESOLVED: Support a single term expanding to multiple IRIs when an array of @ids are associated with a single term in the @context.

[scor]

This was discussed during the call today and some solutions were brought up. Having multiple IRIs for a single term is useful for expressing data, and it's easy to support in the expansion algorithm. It's more of a challenge for the compaction algorithm though, since multiple values have to be compacted into one term when such context is in use (the term doesn't appear as such in the input). The group evaluated the possibility of supporting this feature only during expansion and not compaction, but it would be the first time this would happen in JSON-LD, and it doesn't sound like a good idea. The conneg approach was brought up but rejected. The following resolution was taken:

RESOLVED: Support a single term expanding to multiple IRIs when an array of @ids are associated with a single term in the @context.

The details for the compaction algorithm still need to be worked out, but a possible syntax for the context may look like the following:

{"@context": {"term": {"@id": ["dc:title", "schema:name", "foaf:name"]}}}
{"@context": {"term": ["dc:title", "schema:name"]}}

[msporny]

@linclark The way I implemented this in the spec is slightly different from what you asked for - this is the only supported mechanism right now:

{"@context": {"term": {"@id": ["dc:title", "schema:name", "foaf:name"]}}}

That is, this will not work:

{"@context": {"term": ["dc:title", "schema:name"]}}

The reasoning I used suggested two things; 1) we should try to only have one way of doing this if we can to reduce all of the patterns that authors /reading/ JSON-LD must be aware of and, 2) this is an advanced feature and we don't want authors accidentally triggering it. The only thing pulling me in the other direction was the nicer syntax that you proposed, but that wasn't enough to mitigate the two concerns in the previous sentence.

That said, others in the group might disagree with this approach and you're more than welcome to raise a new issue to support the other syntax in addition to the one added above.

[gkellogg]

Yes, I agree that this is advanced usage, and an expanded term definition is called for.

[linclark]

Thanks for the heads up, the way you propose is fine for us, so no
objection from me.

On Aug 19, 2012, at 3:17 AM, Manu Sporny notifications@github.com wrote:

@linclark https://github.com/linclark The way I implemented this in the
spec is slightly different from what you asked for - this is the only
supported mechanism right now:

{"@context": {"term": {"@id": ["dc:title", "schema:name", "foaf:name"]}}}

That is, this will not work:

{"@context": {"term": ["dc:title", "schema:name"]}}

The reasoning I used suggested two things; 1) we should try to only have
one way of doing this if we can to reduce all of the patterns that authors
/reading/ JSON-LD must be aware of and, 2) this is an advanced feature and
we don't want authors accidentally triggering it.

That said, others in the group might disagree with this approach and you're
more than welcome to raise a new issue to support the other syntax in
addition to the one added above.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/142#issuecomment-7849739.

[lanthaler]

I reopen this issue until the API algorithms have been updated and we decided how this works in compaction.