RDFS / OWL for VC vocabulary?

[peacekeeper]

Hello, I'm curious if there are plans to define an RDF schema or OWL ontology for the VC vocabulary. E.g. what would be the rdfs:domain and rdfs:range of the cred:claim property?

[msporny]

Yes. In fact an experimental JSON-LD Context exists here:

https://w3id.org/credentials/v1

and the experimental vocabulary will exist here:

https://w3id.org/credentials

... and will resemble something like this when we're done:

https://w3id.org/security

The current charter has this ontology as a deliverable:

https://www.w3.org/2017/vc/charter#deliverables

That said, I doubt we're going to be extremely formal with the ontology. It'll be a reference for those that need it, but I don't expect deployed systems to reject data just because one field doesn't fit the rdfs:domain and rdfs:range listed (that or we will be very broad with rdfs:domain and rdfs:range). There is a desire for people that only have JSON tooling to continue to use that JSON tooling w/ Verifiable Claims and "not be bothered" with the more formal semantics. We're trying to strike the right balance, and to do that, we have to have a detailed discussion about all of this in the VCWG.

[ghost]

schemaorg/schemaorg#1654

[stonematt]

@msporny I see w3id.org in the examples in the DM spec. What is the best way to reference these vocabularies and other 3rd party resources that we rely on (DID standards may be another one...)? Is it an appendix, or glossary, or something else?

[msporny]

The group needs to decide if we're going to host the Verifiable Claims JSON-LD context at w3id.org or at W3C. I suggest we do it at w3id.org as it is a multi-organization community controlled space that does one thing and only one thing. It's been operating flawlessly for many years now with hundreds of vocabulary projects depending on it and requires next to no upkeep and resources to keep it going.

Hosting the vocabulary at W3C gives us the same sort of benefit of a long-lived organization, but the downside that the W3C Systems Team has to manage the site for decades. They're already responsible for MANY services and the thought of hosting a service that may be hit many tens of millions of times a day probably doesn't sound very appealing to them.

In any case... the group needs to decide one way or the other. After we do that, @stonematt, it's just a simple matter of NORMATIVELY referencing the URL in the spec.

[ghost]

anyone checked with W3? what's the directors view?

…

On Tue, 3 Oct 2017 at 00:06 Manu Sporny ***@***.***> wrote: The group needs to decide if we're going to host the Verifiable Claims JSON-LD context at w3id.org or at W3C. I suggest we do it at w3id.org as it is a multi-organization community controlled space that does one thing and only one thing. It's been operating flawlessly for many years now with hundreds of vocabulary projects depending on it and requires next to no upkeep and resources to keep it going. Hosting the vocabulary at W3C gives us the same sort of benefit of a long-lived organization, but the downside that the W3C Systems Team has to manage the site for decades. They're already responsible for MANY services and the thought of hosting a service that may be hit many tens of millions of times a day probably doesn't sound very appealing to them. In any case... the group needs to decide one way or the other. After we do that, @stonematt <https://github.com/stonematt>, it's just a simple matter of referencing the URL in the spec. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFdABvm6XekTC_zFqLgJZc3XuficQ-v_ks5soN_bgaJpZM4LqBge> .

[msporny]

@mediaprophet When I spoke to them last, they wanted no part of a resource that would be hit tens of millions of times a day. They were put in this position with the XML DTD work and did not appreciate the constant DDoS by badly implemented software. That was a few years ago. They may have changed their position since then since some WGs are publishing JSON-LD contexts.

Ultimately, this is a WG decision and the Director will only step in if he thinks it may be a problem. I may be speaking w/ TimBL later this week in Boston, so I'll check with him if we have that discussion.

[ghost]

Another left-field idea was something around ISOC / IETF; yet this makes no sense at this stage.

Perhaps some particular TLD is desirable; yet, still makes some sense for such resources to be supported by w3 imho.

[stonematt]

we don't have to look for a "left-field idea" unless it provides some special benefit to the standard. Let's discus in the teleconference time.

[ghost]

whilst its probably an unnecessarily reinforced consideration; the standard is a W3C standard. If constituents need to be hosted somewhere as a 'universal source of truth' in-order for that standard to work; one might consider it be worthy of consideration by the elders.

…

On Tue, 3 Oct 2017 at 02:13 stone ***@***.***> wrote: we don't have to look for a "left-field idea" unless it provides some special benefit to the standard. Let's discus in the teleconference time. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFdABh8bJGNXg8ovQQvprsYpTVjuBsV2ks5soP2LgaJpZM4LqBge> .

[gkellogg]

The CSVW context and vocabularies are managed at W3. The main issue is that the Team Contact is the one that needs to update, otherwise no issue. Given that the TR will be hosted at W3, it makes sense that such closely related resources be there also. Apache settings should ensure resources a catchable, and fully utilizing such caches is a good practice of a JSON-LD processor. This is simplified if there is an update policy that makes such changes infrequent and predictable.