Re: vcard:AddressBook

pá 14. 3. 2025 v 13:01 odesílatel Pierre-Antoine Champin <
pierre-antoine@w3.org> napsal:

> Hi all,
>
> unmaintained vocabularies are not a good thing, so generally speaking, I
> think it would be great if a Community Group took over the maintenance of
> this vocabulary (rdf-dev, rdf-maintenance, or solid are all good candidates
> IMO), and I'm happy to act as an interface with the W3C team to help with
> this.
>
> That being said, I wholeheartedly agree with what Dan wrote below. I think
> that the value of the `vcard:` vocabulary is that it maps to a largely used
> standard (as also pointed out by Tim [1]). Adding features in the `vcard:`
> namespace that do not reflect what's in the IETF VCARD format is sending a
> bad signal.
>
> And that's not even needed! The good thing about RDF is that we can mix
> and match vocabularies, so if the concept of `AddressBook` is not present
> in the VCARD format, an IRI can be minted for it in a *different*
> vocabulary (e.g. FOAF), to be used together with terms from the `vcard:`
> vocabulary...
>

I agree in principle. RDF allows mixing vocabularies, but in practice,
having multiple terms for "AddressBook" can confuse JSON-LD
implementations. If possible, sticking to one term avoids ambiguity and
makes reasoning agents happier.

>
> Now, that being said, if there is a legacy of data and/or applications out
> there that use `vcard:AddressBook`, despite the fact that it was not part
> of the original vocabulary... *maybe* the pragmatic way to do is probably
> to add it to the `vcard:` vocabulary. But it should then be acknowledged
> that this term is a "historical anomaly" rather than an W3C-specific fork
> of the VCARD standard.
>

+1


>    pa
>
> [1] https://github.com/solid/contacts/issues/8#issuecomment-2719050285
> [2] https://www.w3.org/DesignIssues/BagOfChips.html
> On 14/03/2025 11:10, Dan Brickley wrote:
>
>
> (Copying
> mailto:resnick@episteme.net <resnick@episteme.net> from
> https://datatracker.ietf.org/group/vcarddav/about/ on this discussion of
> the maintainability of w3c’s rdf versions of vCard).
>
> I’m repeating myself here but to be crystal clear:
>
> vCard is NOT W3C’s standard. It belongs to the IETF. The W3C documents are
> convenient mappings of that IETF design/schema/vocabulary into RDF’s data
> model. Adding imagined terms into RDF applications using it
>
> The FOAF offer was to put a simple subset isomophic to full vCard in
> somewhere friendly and updatable, whereas adding something into a spec
> labelled vCard but maintained at W3C looks to the whole world as if the Web
> Consortium has forked another standards org’s spec and added new things
> without liaison or coordination (eg on LDAP and XML Schema representations).
>
> Cheers
>
> Dan
>
>
> On Fri, Mar 14, 2025 at 09:43 Peter Rivett <
> pete.rivett@federatedknowledge.com> wrote:
>
>> As someone involved in a few ontology standards myself (a few at OMG
>> including the recently-adopted DPROD extension to DCAT, FIBO at EDM
>> Council, LEI ontology at GLEIF) I find it hard to believe that W3C would
>> appear to effectively abandon such a useful and widely-used standard as
>> vCard. Though, as far as I can see, it was never a formal standard but
>> merely a Member Submission?
>>
>> I agree with giving W3C the chance to respond, and in fact just noticed
>> https://github.com/solid/contacts/issues/8#issuecomment-2719050285 which
>> indicates from the top a willingness to properly maintain it in W3C which
>> I'd fully support.
>>
>> Even if maintained in W3C I think we should aim for the following goals:
>>
>>    - Clear authoritative location (ideally GitHub)
>>    - Published or generated documentation and examples (in addition to
>>    the ontology file)
>>    - Clear transparent process for raising issues/suggesting changes
>>    - Trusted people nominated to manage the process, approve changes and
>>    publish releases
>>    - Namespace with long-term stability that resolves to the ontology
>>
>> I think the W3C DCAT specification meets all the above and would be a
>> good model to follow.
>>
>> Regards
>> Pete
>>
>>
>>
>> Pete Rivett (pete.rivett@federatedknowledge.com)
>> Federated Knowledge, LLC (LEI 98450013F6D4AFE18E67)
>> tel: +1-701-566-9534
>> Schedule a meeting at https://calendly.com/rivettp
>>
>> ------------------------------
>> *From:* Michiel de Jong <michiel@unhosted.org>
>> *Sent:* Friday, March 14, 2025 1:14 AM
>>
>> *To:* Dan Brickley <danbri@danbri.org>
>> *Cc:* Melvin Carvalho <melvincarvalho@gmail.com>; Sarven Capadisli <
>> info@csarven.ca>; semantic-web@w3.org <semantic-web@w3.org>
>> *Subject:* Re: vcard:AddressBook
>>
>> Hi Dan,
>>
>> I wanted to ask for some more details about what you wrote.
>>
>> On Thu, 6 Mar 2025 at 16:08, Dan Brickley <danbri@danbri.org> wrote:
>>
>> I believe the point of that vcard-rdf note was to reflect into RDF the
>> existing vCard design rather than to improve upon it, ie making up new
>> stuff.
>>
>>
>> Is this something that is set in stone? It seems that
>> http://www.w3.org/2006/vcard/ns# was originally created in 2010 with
>> https://www.w3.org/submissions/2010/SUBM-vcard-rdf-20100120/, and then
>> in 2014 https://www.w3.org/TR/vcard-rdf/ updated it. It is now 2025, and
>> in practice we are using 6 "squatted" terms, see
>> https://github.com/solid/contacts/issues/11#issuecomment-2715154170.
>>
>> Who is in charge of deciding the future of
>> http://www.w3.org/2006/vcard/ns#? Is this something we as its users can
>> influence?
>>
>> If so then I see 4 possible ways forward:
>>
>> 1) keep squatting the terms like we are now (not the proper way to
>> practise semantic web, of course)
>> 2) publish a new note (after the 2010 one and the 2014 one), in which we
>> update http://www.w3.org/2006/vcard/ns#
>> 3) move our terms to FOAF and publish them there
>> 4) redesign our addressbook functionality from scratch and switch for
>> instance to SIOC, see
>> https://github.com/solid/contacts/issues/8#issuecomment-2713487899
>>
>> I would like to know what the process would be for option 2.
>>
>>
>> Many thanks,
>> Michiel de Jong
>> Solid CG co-chair
>>
>