Use of the term unambiguously

[melvincarvalho]

In the basic definitions RFC the term unambiguously is used:

WebID -- an identifier in the form of an HTTP URI for unambiguously naming an Agent which, when dereferenced, must always lead to a WebID-Profile Document describing the Agent named by the WebID itself.

What does it mean?

• Is it needed?
• Is it correct?

I am unsure of either of these two points. For example there are examples of Agents that change over time, silly example being Siamese twins that get separated, and so on.

It seems that it's an extra word to be removed, but if there's a good reason for it, perhaps it will add to the spec.

[TallTed]

There's good reason for it.

It is both needed and correct.

Yes, sometimes a WebID identifies a role Agent, which role may be filled by multiple Agents over time, or even at the same time.

I don't see how Siamese twins that get separated — changing from 2 conjoined Agents to 2 unconjoined Agents — are an example of one "Agent that changes over time", but that's probably irrelevant.

To sum up: unambiguously should be retained, exactly where it is.

[melvincarvalho]

There's good reason for it.

What do you consider that reason to be? I was unable to figure that out from the previous reply.

Given that an agent can change, that introduces a degree of ambiguity.

[TallTed]

Every identifier that doesn't incorporate a timestamp has a degree of ambiguity. This is (or should be) a known limitation. Descriptions that incorporate validity dates help address that, but such incorporation is inconsistent, at best.

I find it odd that no-one else is participating in this thread. Perhaps it's not yet clear enough that WebID development is proceeding here?

[melvincarvalho]

Every identifier that doesn't incorporate a timestamp has a degree of ambiguity.

Agree.

This is (or should be) a known limitation.

It's not all that clear how well known this is. There are many edge cases. Consider that foaf : Agent is the parent of foaf : Group. A group can have ambiguous membership, or two groups can both claim to be the same entity.

I think it's also possible to construct non-temporal ambiguity in Agents.

So it's not clear what the term "unambiguous" actually means here, and what assumptions are baked into it. There's probably something to it, maybe there is another word that can be used. The term "unique" crossed my mind, but that might be even worse. In any case I can live with "unambiguous", but it struck me as unclear what it adds.

I find it odd that no-one else is participating in this thread. Perhaps it's not yet clear enough that WebID development is proceeding here?

I think most of the stake holders are aware that work is progressing. They have been pinged several times on github, mailing lists, and instant message. That said, there's not that many of us remaining that have been around this project for a decade or so. And there are many nuances that have been figured out along the way, including this one.

[jacoscaz]

Looking for the meaning of unambiguous leads, amongst others, to this:

• Having or exhibiting no ambiguity or uncertainty; clear.
• Not ambiguous; not of doubtful meaning; plain; perspicuous; clear; certain.

I have a feeling that whether the relationship between a URL and the resource that the URL dereferences to is a clear one or an uncertain one is a debate that probably belongs to the URL standard or possibly to the protocol in use, which for us is HTTP. Perhaps it's not for us to resolve? If so, I would agree with removing the word from the spec.

[melvincarvalho]

Makes sense. It's an interesting topic though for implementers. Another question that arises is whether there can be more than one webid in a profile document. This can also be a source of ambiguity, but the specs can clear that up.

[kidehen]

• Is it needed?

Yes, since entity disambiguation is an intrinsic feature of a name.

An HTTP URI handles that issue at low cost, courtesy of a "#" based indexical, when used to create an entity name.

[woutermont]

If we can conclude one thing from this discussion, it is that we should probably look for an alternative for the term "unambiguously", since it obviously leads to some unnecessary confusion. We could replace it by speaking of "a unique Agent", or by adding: "A single WebID cannot name two different Agents," for example.

[jacoscaz]

Agree on finding a different formulation. I would tweak yours as follows, though I already find your version more than acceptable.

A single WebID cannot name two different Agents at any single point in time

[woutermont]

I think that such an addition would rather encourage bad practices. Cool URIs don't change, and I believe the WebID spec should at least recommend that WebIDs are Cool URIs (i.e. they SHOULD not name different agents).

[jacoscaz]

I think that such an addition would rather encourage bad practices. Cool URIs don't change, and I believe the WebID spec should at least recommend that WebIDs are Cool URIs (i.e. they SHOULD not name different agents).

@woutermont indeed, I think you are right. Speaking without my chair hat, this makes me go back to my initial gut feeling:

I have a feeling that whether the relationship between a URL and the resource that the URL dereferences to is a clear one or an uncertain one is a debate that probably belongs to the URL standard or possibly to the protocol in use, which for us is HTTP. Perhaps it's not for us to resolve? If so, I would agree with removing the word from the spec.

I reckon we don't need unambiguously nor any other qualifier. The more we can leave to upstream spec / standards / guidelines, the better.

[jacoscaz]

Speaking with my chair hat on, can everyone indicate whether they find any of the following alternatives completely unpalatable?

1. keeping unambiguously
2. removing unambiguously
3. replacing unambiguously with a unique Agent
4. removing unambiguously and adding the note a single WebID cannot name two different Agents

Also, and this is a separate question, can everyone indicate whether they would have anything against mandating WebIDs to be Cool URIs?

@woutermont @melvincarvalho @kidehen @TallTed

[jacoscaz]

Back to speaking as myself, my personal vote goes for option 2., thinking that this is something that should be clarified upstream, and that the WebID spec should absolutely mandate WebIDs to be Cool URIs.

[woutermont]

While the Web would be a much cleaner place if this was 'solved' upstream, there are good (practical) reasons for not doing so, and I do not suspect we will ever see a time where URIs will be immutable by design. So I believe it is important to stress these aspects in the WebID spec.

I am therefore not in favour of 2. I think 1 is still acceptable, but believe a change to 3 and/or 4 is preferable for clarity.

[csarven]

I don't particularly see anything that warrants a "vote" here.

First off, if the text is of editorial in nature, and the correction class is 1-2, the text would be deemed as appropriate or left at the discretion of the editor. If there is something technically wrong with the text, by all means, make a correction.

Second, the correction that's being discussed here is requesting a clarification on a proposal - which should've been done against the PR itself instead of spinning up a new issue. After all, the PR that proposed to rewrite (or as part of new set of specs?) was deemed to be too big of a change. So..

Third, counting or "sensing" supported approaches (based on few that are present or able to respond here) is generally not adequate to move something forward. It could be used as a last resort if there is a technical stall. Even in that case, work towards reducing or removing objections tends to be the safest and balanced route.

I would add that much of the above is a recurring issue in some other issues and PRs as of this writing...

---

The CG / specifications provide requirements, not mandates. Something like "Cool URIs" is considered to be a best practise or advisory. Much of it is reflected in the Architecture of the World Wild Web (e.g., see https://www.w3.org/TR/webarch/#uri-assignment ), and that would serve as a better point of reference. The WebID specification doesn't need to have requirement level such as a SHOULD at all. It adds nothing to interoperability. Anything of such can be a general coverage in the Introduction or under Considerations ( https://github.com/w3c/WebID/issues/28 )

[kidehen]

Cool URIs don't change, and I believe the WebID spec should at least recommend that WebIDs are Cool URIs (i.e. they SHOULD not name different agents).

"Cool URIs" is just a longwinded and buzzy way of saying: Denote entities unambiguously using HTTP URIs.

"Cool URIs", "Linked Data Principles", and other phrases and memes, are various attempts (over the years) to frame the benefits of unambiguous entity naming using HTTP URIs.

[kidehen]

Makes sense. It's an interesting topic though for implementers. Another question that arises is whether there can be more than one webid in a profile document. This can also be a source of ambiguity, but the specs can clear that up.

You can have a zillion WebIDs in a profile document, as long as each is denoted unambiguously using an HTTP URI.

[woutermont]

Makes sense. It's an interesting topic though for implementers. Another question that arises is whether there can be more than one webid in a profile document. This can also be a source of ambiguity, but the specs can clear that up.

You can have a zillion WebIDs in a profile document, as long as each is denoted unambiguously using an HTTP URI.

True.

"Cool URIs" is just a longwinded and buzzy way of saying: Denote entities unambiguously using HTTP URIs.

Less true. Cool URIs, even though they are an ill-defined buzzword, comprise more than unambiguous reference. The reason I mention them here is because, on top of refering unambiguously, they are also immutable, i.e. they remain unambiguous.

[melvincarvalho]

Not a strong view on this either way, mainly wanted to understand what @kidehen meant by the term vs unique vs leaving it out.

[kidehen]

Less true. Cool URIs, even though they are an ill-defined buzzword, comprise more than unambiguous reference. The reason I mention them here is because, on top of refering unambiguously, they are also immutable, i.e. they remain unambiguous.

The point here is that names denote things unambiguously, by their very essence. Implementing that in computing can be challenging, but an HTTP URI simplifies matters based on HTTP ubiquity. Just add "#this" to the URL of this post and you have an unambiguous entity name that denotes said post, courtesy of an HTTP URI.

The essence of a name lies in the following:

1. Being unambiguous
2. Being resolvable to some connotation of its referent via= indirection provided by the realm within which it functions

This also why you can have a zillion WebIDs in a single WebID-Profile document.

[kidehen]

Not a strong view on this either way, mainly wanted to understand what @kidehen meant by the term vs unique vs leaving it out.

This is due to the fact that attempting to use URLs as unambiguous entity names doesn't work. You solve that problem via a "#" based indexical or indirection using 303 redirection.

As you know, these are old controversies that are being addressed by using clearer language to (hopefully) instruct practitioners toward proper entity naming without dreaded the http-range distraction and confusion.

A WebID only works if it unambiguously names an agent using an HTTP URI. In fact, that's an immutable point.

[melvincarvalho]

@kidehen thanks. That explains where you are coming from. A lot of history packed in that one word! It makes sense, this can be closed.

[jacoscaz]

/chair hat on

I don't particularly see anything that warrants a "vote" here.

@csarven I have not formally called for a vote. I did use the word vote, yes, and I'll be more careful in the future not do so outside of the context of a formal vote, but I'm only trying to gauge where we each stand.

First off, if the text is of editorial in nature, and the correction class is 1-2, the text would be deemed as appropriate or left at the discretion of the editor. If there is something technically wrong with the text, by all means, make a correction.

This refers to a specific process we have not yet chosen as our own. Insofar as that stands, I will generally opt to gauge consensus in a less formal manner unless the group objects to me doing so.

[jacoscaz]

/chair hat on

It feels like we can keep unambiguously where it is and consider this issue resolved? Mh... On second thought, maybe I would wait for @woutermont 's feedback.

[woutermont]

Sure. For me that's fine. My view just was that if it is indeed unclear for some people, a simple change to 'unique' would solve it. But apparently other people think that change is not so simple, so let's leave it as is.

[jacoscaz]

Nice! @melvincarvalho , if you're satisfied please consider closing this at your convenience.

[csarven]

@jacoscaz , do you agree with the following:

the consensus here is about the underlying intent of the design, and that using specific wording is typically the editors responsibility with the understanding that it follows the agreement on what's intended.

[jacoscaz]

@csarven I think I generally agree, yes, though I don't see it as an either - or dichotomy. This issue was raised against proposed definitions which have not (yet) been added to the spec, which makes them easier to iterate upon. Insofar as possible, I would try to adhere to both intent and letter. To your point, though, intent takes precedence over letter.

[TallTed]

[@jacoscaz] gauge consensus

This is often done well by a simple poll, which can look a lot like a vote, but is not intended to make a decision, but rather, to gauge whether one direction is a non-starter (for instance, if some participant(s) would formally object if that direction were made final, usually signaled by a -1, or if all participants signal that they don't like this direction with a - fraction) or whether another direction is universally liked (all "votes" being +1 or fraction thereof; none negative)...

Polls are most often used, and are usually most effective, during regularly scheduled conference calls (with parallel IRC or similar side-chat, typically used both for side-chatter and logging, which become the basis for published minutes) where a group meets to discuss the work.

A lot of work can be done via mailing lists, and via GitHub Issues/PRs, but there is little substitute for the broader bandwidth of conference calls and/or video-chats. Occasional (often twice a year; commonly yearly; relatively rarely less frequent than once a year) Face-to-Face (F2F) where the whole group travels to one location and meets for 1-3 days solid, commonly going out to dinner as a social anchor. Many groups in which I've participated have made major progress during F2Fs, including large-scale refactoring and/or rewriting of drafts in progress, because the extra bandwidth of facial expressions, hand gestures, napkin sketches, etc., makes communication of challenging and detailed technical details enormously easier, faster, and clearer.