-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Web Discovery? #54
Comments
/chair hat off When in doubt, simplify... If its meaning is not clear, we can start with dropping |
I'm in favor of dropping In my mind, |
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. |
/chair hat on To all: as much as we can, let's try to keep things separate. This issue is about the word 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. |
"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. |
@kidehen do see the top issue and the usage in the old ed, essentially it's non existent and unspecified. |
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. |
/chair hat off
Good point. I think it'd be enough to add this in the abstract to clarify the role of the word Discovery. |
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. |
Yes, and it packs follow-your-nose discovery into a single word. Discovery is an important aspect of a WebID. |
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. |
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: |
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 |
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. |
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. |
Not so simple.
"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. |
Hmm, I dont think the ID in WebID has ever stood for "identification".
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.
+1 |
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 :) |
I guess perhaps they can be seen as redundant and adding needless complexity. Web = Web 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. |
No objections, given Ted and Kingsley are at the same company, perhaps they could figure out between them what they want? |
I have a strong objection to keeping Removing Discovery leaves |
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. |
The body text can be enhanced to shed light on discovery scenarios facilitated by a WebID. We can even put that together, if necessary. |
+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. |
/chair hat on The current title of the working draft (link rendered version) is Summarizing the above and based on past conversations, I think we have the following alternatives to pick from:
/chair hat off No blockers on my end but soft preference for option 2. , with the following paragraph as the additional detail:
|
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. |
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
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 howWebID
deliversDiscovery
of more than alternate RDF serializations.The text was updated successfully, but these errors were encountered: