Migrating non-existing vCard terms to a separate solid-extension-to-vcard vocab #8
Comments
|
Better start with the use cases to understand where things could go. I don't find foaf:AddressBook to be a good/adequate path considering the key part is about vCards, and there is no compelling reason to mix vCard and FOAF's needs/approaches in this arbitrary way. If a class is really desired, existing http://rdfs.org/sioc/types#AddressBook may be sufficient, which acts as a collection/container. See also http://rdfs.org/sioc/spec/#sec-modules-types One of the things that's being sought as I understand it is about expressing a container/collection, i.e., the addressbook holding vcards, and the other thing is about its discovery. For the collection, generally "Container contains CardA, CardB" could work. (or "Collection items CardA, CardB" etc..) This is similar to CardDAV's Address Book Data Model. Alternatively, vCard's "Group hasMember VCard" can be used to both collect and discover the vCards. For some systems, the class will be sufficient (like SPARQL query, or specs explicitly stating to look up that class), but generally, for follow-your-nose kind of exploration, a property indicating that something has an addressbook/cardlist etc. |
Thanks for bringing this up. We're already mixing the
I don't think I understand what you are proposing here, is the purpose to remove the need for an |
Ah, thanks for updating your comment, I understand better now. Sure, if we already had a desire to switch addressbooks from a Thing to a container, then it would make sense to take this opportunity to do so. So let's investigate that question in a separate issue: #9. If we decide we want to stick to the current design of our |
|
What's the relationship between a vcard:AddressBook (or foaf:AddressBook) and vcard:VCard? How does that FYN currently happen? Is it specific to some set of applications, one application, a set of use cases, a spec? Once an AddressBook is discovered, how are the VCards discovered? sioct:AddressBook (which actually exists, and better to reuse than squat or invent yet another, no?) in all likelihood is going to act very much like vcard/foaf:AddressBook. Again, perhaps first write the use cases, or define what vcard:foaf:AddressBook really is, as well as its relationship to or inverse from vcard:VCard (or specific kinds of), then go from there. SIOC is a W3C Member submission: https://www.w3.org/submissions/sioc-spec/ . A "container" is still a "thing", and depending on what that container is, the property that helps to discover its contained objects is usually available (e.g., dcterms:hasPart, ldp:contains, as:items, sioc:container_of). My point is that, just defining the class is not going to be enough unless its use is intended to be very narrow in scope. For it to be generally useful, what's needed:
The properties alone would be sufficient for FYN. Class can be useful for other cases (like querying for instance). So, sioct:AddressBook + sioc:container_of + vcard:VCard (or its kinds) would literally solve this problem right now, but it is impossible to discuss this further meaningfully without actually writing out what's really needed. Just saying foaf:AddressBook is a possibility is not a strong argument as I see it, considering all of the above that's mentioned. YMMV. |
@csarven if you're asking this because you don't know, then see #11. I agree the documentation is a bit lacking, and we should improve it. But that's a separate topic, we can discuss that there. Furthermore, if you have a proposal for improvement of how this client-client spec works, then you can comment on #9 and/or open a separate issue about it. But let's not get tempted to reinvent the wheel if there's no need for it, because the way this works and how the current client-client spec serves its use cases has been stable for at least 5 years, and it is not up for discussion. At least not in this discussion - let's stay on-topic about the ontology migration please! I added this topic (the ontology migration, that is) to the CG call agenda for next week: https://hackmd.io/NR7hHvEbQcKDBHEJUh4hXg#Moving-AddressBook-from-vcard-to-foaf |
|
I've mentioned and asked a bunch of things but you seem to have sidestepped the most of it. If you just want a Class, I pointed you to the existing sioct:AddressBook. You seem to be dismissing that because it doesn't match your issue's question about whether to "migrate" to FOAF, which by the way, is still very much hypothetical, and still needs discussion, use cases, and consensus to introduce to FOAF - not to forget, a vocabulary that is not particularly maintained since the migration to schema.org. That's all meanwhile you're drafting a "plan" with dates and everything for the migration. It seems to be that you have made up your mind, so I don't know what you're really after other than trying to get agreement as opposed to taking just a moment to consider and discuss what may be really needed here. I'm all ears to your definition of foaf:AddressBook (with zero guarantee that it will actually happen) in contrast to sioct:AddressBook. Let me just say that I don't have a horse in this race. As I've said earlier, all that I brought up are considerations to unpack whatever you think you are trying to do. It seems I've overstayed my welcome in this issue, so, I'll bow out and let you work it out from here. |
|
I strongly disagree with the proposal to migrate from the W3C vcard: ontology (http://www.w3.org/2006/vcard/ns#) to FOAF.
"A dead end" in what sense? Not being maintained? Let's maintain it. |
|
Seems like the main issue is just structuring a vCard collection with some categories (‘Personal’, ‘Work’, etc.). If we’re keeping vCard, let’s define AddressBook cleanly. The real question is how change control works in practice—if it’s possible, it should help apps evolve quickly. |
|
Discussed in today's CG call. We'll migrate to a newly created 'Solid extension to vcard' vocabulary. |
|
|
Namespace URL and commonly used prefix tbd. I'll create the ontology description, the PR to SolidOS, and the PR to Solid Data Modules soon. |
|
@michielbdejong I totally agree that devs need to be able to work without blockers. But just out of curiosity—what exactly would break if we simply kept things as |
|
Given positive reaction so far from IETF, let's see if we can get edit https://www.w3.org/2006/vcard/ns# with the terms in #12. If that fails, we can still do the migration [EDIT: if the SolidOS team agrees and accepts our PR to do so]. |
|
Great news, |
|
It'd be great if you can provide any references to: Who decided to add it? Who added it? Who was informed about the update? How were you informed about the update? |
|
Yes, the discussion got to https://lists.w3.org/Archives/Public/semantic-web/2025Mar/0143.html and then @pchampin did the hard work of getting it updated! :) |
|
Great work @michielbdejong ! |
As suggested in https://lists.w3.org/Archives/Public/semantic-web/2025Mar/0012.html - since it seems that the
vcard:AddressBookwe are currently using is a bit of a dead end, we might switch tofoaf:AddressBook.I would like to give this a shot, but starting with an invitation for community feedback.
We could for instance take:
Would that be a reasonable playbook for a possible migration like this?
The text was updated successfully, but these errors were encountered: