Web Discovery?

[TallTed]

The 2014 ED has 2 instances of "discovery" (and none of "discover") — and one is in the subtitle.

The other is in context of Content Negotiation — i.e., it's just about discovery of multiple distinct serializations of the same graph at the same URL

WebID requires that servers <em class="rfc2119" title="MUST">MUST</em> at least be able
to provide Turtle representation of profile documents, but other serialization formats
of the graph are allowed, provided that agents are able to parse that serialization and
obtain the graph automatically.

HTTP Content Negotiation can be employed to aid in publication and discovery of multiple
distinct serializations of the same graph at the same URL, as explained in
[<cite><a class="bibref" href="#bib-COOLURIS">COOLURIS</a></cite>]</p>

If we're going to keep the subtitle (or now, title!) of Web Identity and Discovery (WebID), I think we need some significant discussion of how WebID delivers Discovery of more than alternate RDF serializations.

[jacoscaz]

/chair hat off

When in doubt, simplify... If its meaning is not clear, we can start with dropping Discovery from the title.

[TallTed]

I'm in favor of dropping Discovery.

In my mind, WebID uses ID in a way any database or driver's license user is familiar with, and just drops a space and changes {IDentifier|IDentification|IDentity} to ID — i.e., it mentally expands to Web IDentifier, Web IDentification, and/or Web IDentity (depending on the specific context of its appearance, as I hope we can all agree there are significant differences between these three expansions of ID).

[webr3]

Agree with both comments, Ted makes a critically important point here about the expanded meanings of ID.

The recursive acronym may complicate things as we move forward.

[jacoscaz]

/chair hat on

To all: as much as we can, let's try to keep things separate. This issue is about the word Discovery. Dropping it from the title we settled on in #37 would lead to Web Identity (WebID), which insofar as I can tell has an element of recursion in it.

Personally I'm still not grokking the recursion argument but @kidehen and others have been making the case for it for a long time with no objections. We can re-evaluate having a recursive-ish title, of course, but let's do so in a different issue if needed at all.

[kidehen]

"Discovery" deals with the "reference" and "lookup" aspects of a WebID i.e., its resolution to a profile document. That's why it exists in the current spec.

A WebID provides a starting point for follow-your-nose exploration of a variety of things associated with a WebID's referent.

It shouldn't be altered, since that will ultimately taint the progress made so far -- IMHO.

[webr3]

@kidehen do see the top issue and the usage in the old ed, essentially it's non existent and unspecified.

[TallTed]

A WebID provides a starting point for follow-your-nose exploration of a variety of things associated with a WebID's referent.

OK... Then at a minimum, I would expect an example of such to be found in the text of the document. I find no such in the latest 2014 ED. The closest I found in the Mercurial dump of that document's history was in a (long since excised) section connecting WebID to OpenID, which removal appears to have been appropriate given that neither WebID nor OpenID depends on the other in any ongoing way.

[jacoscaz]

/chair hat off

A WebID provides a starting point for follow-your-nose exploration of a variety of things associated with a WebID's referent.

Good point. I think it'd be enough to add this in the abstract to clarify the role of the word Discovery.

[melvincarvalho]

I dont understand the importance of the "recursive" part, nor do I know anyone that likes the "recursive" part. That could be better explained.

@deiu introduced the term 'discovery' in 2013, which I think just meant using linked data to discover things.

[kidehen]

Yes, and it packs follow-your-nose discovery into a single word. Discovery is an important aspect of a WebID.

[melvincarvalho]

As we discussed back then, though, discovery is different from follow your nose. For example, webfinger is discovery, but does not use follow your nose.

Much of this will be self-evident with examples.

I think framing it as entities, attributes and values using JSON will be much more intuitive to Web Developers, than emphasizing RDF and Turtle. So, I prefer the term "machine readable" with reference to data, and then for the "discovery" aspect to become self-evident from worked examples. Copy-paste, then change to suit deployment needs. Seems the path to success.

[kidehen]

Follow-your-nose is just a TimBL-ism for dereferencing and graph structure constructed from pointers. That process facilitates discovery.

Programmers understand the concept of 'data access by reference' in relation to structured data representation. The key point here is that "Discovery" is a single word that associates all of this with an HTTP URI, in the context of a specification titled 'WebID and Discovery' :)

Asking ChatGPT to put this all together and it produced a pretty useful response: "Programmers are familiar with the concept of 'data access by reference' in the realm of structured data representation. This concept is pivotal in understanding how data elements are interconnected and accessed in a structured manner. The essence of this concept is succinctly encapsulated in a single, powerful word: 'Discovery.' This term gains even more significance in the context of the 'WebID and Discovery' specification, where it's linked directly to HTTP URIs. Understanding 'Discovery' within this framework is key to grasping the full potential and functionality of the 'WebID and Discovery' specification. It's not just about locating resources; it's about establishing a more intuitive and interconnected web of data, accessible through standardized references."

[melvincarvalho]

Yes, but discovery is not the same as follow your nose, though follow your nose is an aspect of discovery

Discovery is not the same as data access by reference, though data access by reference is an aspect of discovery

Discovery is about having machine readable data, and through a process discovering more machine readable data

[kidehen]

Put differently, a WebID opens up a world of discovery. This is a fact, due to the nature of an HTTP URI that resolves to an entity relationship graph comprising machine-readable entity relationship type semantics.

[webr3]

The key point here is that "Discovery" is a single word that associates all of this with an HTTP URI,

I'd posit that the term Web in WebID, is in fact the single word that associates all of this with an HTTP URI.

[melvincarvalho]

I'd posit that the term Web in WebID, is in fact the single word that associates all of this with an HTTP URI.

That's a pretty powerful observation. The term "web" is so overused, that it's become a cliche. Yet actually delivering a a first class "Web" Identity system is what this group has always been about.

Indeed, I would argue none exist today, that can be deployed at scale. We have a chance to fix that.

[kidehen]

I'd posit that the term Web in WebID, is in fact the single word that associates all of this with an HTTP URI.

Not so simple. ID can stand for:

1. Identity -- what an identifier enables
2. Identification -- what a profile doc enables

"Discovery" solves for the issue of 1 or 2, which is how I believe the original spec ended up with "WebID Identity and Discovery" 

I really think we should leave this as is, there are bigger issues to handle e.g., sorting out JSON-LD support. That's the biggest material issue -- IMHO.

[melvincarvalho]

Not so simple. ID can stand for:

1. Identity -- what an identifier enables

2. Identification -- what a profile doc enables

Hmm, I dont think the ID in WebID has ever stood for "identification".

"Discovery" solves for the issue of 1 or 2, which is how I believe the original spec ended up with "WebID Identity and Discovery"

The original term discovery was introduced here because it was essential to discover a nested key from from a WebID e.g. using complex tech such as SPARQL. Actually it can be traced back to 2012 if you follow the minutes, but then things get a bit lost.

I really think we should leave this as is, there are bigger issues to handle e.g., sorting out JSON-LD support. That's the biggest material issue -- IMHO.

+1

[kidehen]

The original term discovery was introduced here because it was essential to discover a nested key from from a WebID e.g. using complex tech such as SPARQL. Actually it can be traced back to 2012 if you follow the minutes, but then things get a bit lost.

Okay, and I don't see how anything you've stated above is incompatible with the variety of explanations I've provided about the meaning of "Discovery" in the original spec.

There's something to "discover" when you resolve a WebID to an entity relationship graph comprising machine-readable entity relationship type semantics :)

[webr3]

I guess perhaps they can be seen as redundant and adding needless complexity.

Web = Web ID = ident*

It covers everything

[kidehen]

I guess perhaps they can be seen as redundant and adding needless complexity.

Web = Web ID = ident*

It covers everything

I disagree, especially as we should be seeking to only make important (i.e., blocking) changes, unobtrusively, to the current spec. Fundamentally, "Discovery" is already in use -- so I encourage leaving it as is.

JSON-LD parity with Turtle is a much more important issue.

[jacoscaz]

/chair hat on

@TallTed is yours a strong objection to keeping "Discovery" or could you live with it?

@kidehen is yours a strong objection to dropping "Discovery" or could you live with it?

Does anyone else have strong objections towards one or the other?

[melvincarvalho]

No objections, given Ted and Kingsley are at the same company, perhaps they could figure out between them what they want?

[webr3]

I have a strong objection to keeping Identity and Discovery it's redundant and sets a wordy tone for the approach to the rest of the document.

Removing Discovery leaves WebID Identity - something so clearly redundant I'd presume it wouldn't even be worth discussing.

[TallTed]

I'm fine with keeping Discovery in the title if the body content gets some more detail about that element of "discovery". The single sentence now containing that word (and zero sentences including the word "discover") is not sufficient, imho, especially given the number of sentences about "Identity".

Perhaps some text could be added about how to "discover a nested key from from a WebID, e.g., using complex tech such as SPARQL" or even using simpler tech such as a Turtle (or JSON-LD) parser?

---

I think the titles we're debating are "WebID — Web Identity and Discovery" and "WebID — Web Identity".

I don't think "WebID Identity and Discovery" nor "WebID Identity" are being considered.

[kidehen]

The body text can be enhanced to shed light on discovery scenarios facilitated by a WebID. We can even put that together, if necessary.

[melvincarvalho]

I'm in favor of dropping Discovery.

If its meaning is not clear, we can start with dropping Discovery from the title.

I have a strong objection to keeping Identity and Discovery

+1 Discovery is not necessary in a micro spec, and has never been defined

From reading this thread, outside of Openlink, no one is pushing for this.

Suggest closing.

[jacoscaz]

/chair hat on

The current title of the working draft (link rendered version) is Web Identity and Discovery, though this is likely a mistake as #37 pointed towards Web Identity and Discovery (WebID) 1.0.

Summarizing the above and based on past conversations, I think we have the following alternatives to pick from:

1. Web Identity and Discovery (WebID) 1.0 as-is
2. Web Identity and Discovery (WebID) 1.0 with some more detail about the "discovery" element
3. Web Identity (WebID) 1.0

/chair hat off

No blockers on my end but soft preference for option 2. , with the following paragraph as the additional detail:

A WebID provides a starting point for follow-your-nose exploration of a variety of things associated with a WebID's referent.

[webr3]

3 Looks good.

Lots of things are mentioned in the spec, but are not mentioned in the title, and people understand what web entails these days.

ID itself is the most common short for of Ident*.

Having "and Discovery" implies that a web identifier or identity should be a "WebI", since the D part is for something else. Irrational.