Re: vcard:AddressBook

čt 3. 4. 2025 v 17:06 odesílatel Michiel de Jong <michiel@unhosted.org>
napsal:

> Yes, sounds like a versatile and flexible solution, but setting up such a
> per-term list would be redesigning the semantic web, wouldn't it?
> For now, I have good hope that we can get it working at its
> current location, so no need to go to such lengths, I think.
>
> I opened an issue for W3C staff here:
> https://github.com/w3c/w3c-website/issues/716
> which looped me back to this mailing list, and I also tried contacting a
> couple of W3C staff members directly, to which I got no response, but I'm
> sure sooner or later someone at W3C staff will be able to make the edit for
> us. :)
>

Great question!

Would a term list mean redesigning the semantic web? Yes and no.

The semantic web was always about different namespaces working together —
each doing its own thing. Just like the web itself.

Where we do need some design is versioning. The average lifetime of a URI
on the web is ~200 days. After a few years, vocabularies disappear, things
break, and we have no standard way to handle it. Whether something changes
or stays the same, it ripples.

What’s missing is a reliable place where semantics are maintained and
versioned. If a term drops off, there's at least some fallback. Term lists
could help, but what’s really needed is a proper versioning mechanism —
Memento doesn’t quite cut it.

The nice thing about a term list (similar to JSON-LD context) is you can
glance at it, see the terms and where they live. Optional, but useful. If
it helps, devs will use it.


>
> Cheers,
> Michiel de Jong
> Solid CG co-chair
>
> On Thu, 3 Apr 2025 at 14:15, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> út 25. 3. 2025 v 10:43 odesílatel Michiel de Jong <michiel@unhosted.org>
>> napsal:
>>
>>> The reaction on the Calsify mailing list (from my respected personal
>>> friend Hans-Joerg Happel) sounded positive:
>>> https://mailarchive.ietf.org/arch/msg/calsify/17sFwUiDu-zp77vbiQBJRjR-_L8/
>>> There was also a thumbs-up from Pete Rivett on Tim Berners-Lee point
>>> here: https://github.com/solid/contacts/issues/8#issuecomment-2719050285
>>>
>>> That makes me think that adding the terms from
>>> https://github.com/solid/contacts/pull/12/files?short_path=d90e4ed#diff-d90e4edb2d214338309e8948af2f00da8dac0954ae325f903ad5b85d9ae6e9e5
>>> into https://www.w3.org/2006/vcard/ns could be a reasonable path
>>> forward? What would be the next step to explore that?
>>>
>>> And in general, can we (as a DX improvement) create links from
>>> https://www.w3.org/2006/vcard/ns to https://www.w3.org/TR/vcard-rdf/
>>> and the other documents that describe it?
>>>
>>
>> I think this issue really highlights the bigger challenge of having a
>> stable URI for terms, versus getting blocked as a developer.
>>
>> There’s probably no one-size-fits-all solution here — it likely depends
>> on the developer’s preference in the end.
>>
>> That said, I think it would be super helpful to maintain a list of terms
>> that map to stable locations. You could start with the usual schema.org
>> ones and then gradually add common terms. If something like vCard changes
>> over time, just update the reference. Feels like a nice middle ground for
>> folks trying to balance existing vocabularies with keeping things unblocked.
>>
>> It wouldn’t have to be mandatory, of course — but it might really help
>> those who want to move fast without getting tangled up in red tape. I’d be
>> happy to help maintain a mapping like that if it would be useful.
>>
>>
>>>
>>> Many thanks,
>>> Michiel de Jong
>>>
>>> On Thu, 20 Mar 2025 at 16:19, Sarven Capadisli <info@csarven.ca> wrote:
>>>
>>>> On 2025-03-20 15:52, Michiel de Jong wrote:
>>>> > Thanks! I asked them how they would feel about vCard-related RDF
>>>> terms
>>>> > existing only at W3C: https://mailarchive.ietf.org/arch/msg/calsify/
>>>> > TtTXanhR-iK39MUIiaQv41lnS7U/ <https://mailarchive.ietf.org/arch/msg/
>>>> > calsify/TtTXanhR-iK39MUIiaQv41lnS7U/>
>>>>
>>>>
>>>> If you want to increase the chances of getting new terms into vCard, I
>>>> suggest dialing back on Solid. Sharing implementation experience is
>>>> very
>>>> useful, but be prepared to generalise it - without making it seem
>>>> Solid-specific - so that it has broader applicability and a higher
>>>> chance of gaining wider support. Anything Solid-centric for vCard use
>>>> will most likely need to remain within the Solid ecosystem.
>>>>
>>>> -Sarven
>>>> https://csarven.ca/#i
>>>>
>>>>