- From: Timothy Holborn <timothy.holborn@gmail.com>
- Date: Wed, 12 Mar 2014 22:28:12 +1100
- To: Joseph Potvin <jpotvin@opman.ca>
- Cc: Web Payments CG <public-webpayments@w3.org>, Kingsley Idehen <kidehen@openlinksw.com>
Understood.
I'm think language helps sort out what will enviably become discussed in courts, to be decided by judges, where the vast majority of such "umpires" will not understand technology either.
Getting ontologies right is important.
Sent from my iPad
> On 12 Mar 2014, at 10:07 pm, Joseph Potvin <jpotvin@opman.ca> wrote:
>
> Follow-up to the Supplemental:
>
> This is why it's essential for developers and managers themselves
> "have a clue" about the underlying (...overarching?) legal concepts
> that they need to deeply internalize in their work.
>
> In any organization, legal counsel advises, and sometime may "call the
> shots", but as Lessig observed in "Code is Law", systems developers
> and systems development architects and managers are the ones with the
> cue in their hands, the eye-alignment, and who determine where the
> ball actually goes. Legislation and case law are documentation, which
> may or may not be accurate or up-to-date.
>
> Systems developers and systems development architects and managers
> need (and very many actively want) to dig deeper into understanding
> the concepts in law that they need to apply directly. Certainly
> lawyers need to dig deeper into understanding mathematics, however not
> many lawyers will read this stuff:
> http://www.groklaw.net/article.php?story=20121013192858600
>
> By not learning much mathematics, most lawyers must rely on some broad
> metaphors. The problem is they then very often then mistake the
> metaphors for the real thing (eg "metadata: it's just billing data").
> The gap tends to be more readily filled in by developers engaging
> some advanced legal concepts (because many of them are able to) than
> by lawyers engaging some advanced mathematics concepts (because most
> of them are not able to).
>
> Joseph Potvin
>
>
>> On Wed, Mar 12, 2014 at 6:26 AM, Tim Holborn <timothy.holborn@gmail.com> wrote:
>> A Supplemental
>>
>> "Senator LUDLAM (Western Australia) (14:08): Mr President, I ask a final
>> supplementary question and we will see if we do any better with this one.
>> Will the Attorney-General assist the Prime Minister to understand what
>> metadata actually is, given he stated yesterday it was simply billing data
>> when in fact metadata reveals mobile and landline phone records, a person's
>> precise location, the source and destination of electronic mail, their
>> entire social network and their web history? Could the Attorney please give
>> an undertaking to remind the Prime Minister of what this term actually
>> means?
>>
>> Senator BRANDIS (Queensland--Deputy Leader of the Government in the Senate,
>> Vice-President of the Executive Council, Minister for Arts and
>> Attorney-General) (14:09): I think the honourable senator, if I may say so,
>> assumes too much, because the term 'metadata' is not a term of art; it is a
>> term that means different things to different people. I can tell the
>> honourable senator that, during the parliamentary inquiry to which I
>> referred in my answer to his first supplementary question, a number of
>> witnesses gave different definitions of what they understood to be metadata.
>> I myself, on the basis of having been informed by the evidence of those
>> several witnesses during the last parliament, thought that the Prime
>> Minister's description of metadata as essentially billing details was a
>> perfectly accurate, shorthand description of what is a contestable concept.
>>
>> source:
>> http://parlinfo.aph.gov.au/parlInfo/search/display/display.w3p;db=CHAMBER;id=chamber%2Fhansards%2F2920c44d-a6eb-4db5-99ca-95422bf3aa7c%2F0022;query=Id%3A%22chamber%2Fhansards%2F2920c44d-a6eb-4db5-99ca-95422bf3aa7c%2F0000%22
>>
>> On 12 Mar 2014, at 7:35 pm, Joseph Potvin <jpotvin@opman.ca> wrote:
>>
>> Tim, Very interesting outline to aid thinking.
>>
>> For anyone in need of a good headache, I'll add that there's a
>> requirement also to take into account some additional meta-layer
>> issues:
>> (a) the allocation of the right/responsibility to choose which aspects
>> of an agent's identity applies to any particular transaction;
>> (b) the allocation of the right/responsibility to choose which
>> jurisdiction's rules govern the allocation of the right/responsibility
>> to choose aspects of an agent's identity that shall apply to
>> transactions or things;
>> (c) the allocation of the right/responsibility to recognize, or to not
>> recognize, jurisdictions.
>>
>> Layer (a) can be considered grounded in the originally French legal
>> concept of "droits morales"
>> http://www.artslaw.com.au/info-sheets/info-sheet/moral-rights/ (for
>> anyone who is not familiar with the terminology context, this is not
>> about "moral=ethical", it is about "morale=attitude" as in the phrase
>> "team morale"). ...though I'll bet it probably all traces back to
>> Aristotle! Here's a summary in Australian (based on Brit) law:
>> http://www.artslaw.com.au/info-sheets/info-sheet/moral-rights/
>>
>> Layer (a) in a web payments realm will include, say, the right to
>> determine whether one's trade is taxable or not (Are "you" or are
>> "you" not "in the business" of fixing bicycles for a living?)
>>
>> Layer (b) has been playing out recently in relation to Bitcoin, which
>> is getting decided not at that realm, but via Layer (c).
>>
>> Layer (c) is determined by legal/ethical "doctrine" or "principle".
>> For example, there's the "Principle of Paramountcy" (example, in
>> Canadian federalism
>> https://en.wikipedia.org/wiki/Paramountcy_%28Canada%29 ... sort of the
>> "I'm more comprehensive than you are" ethic). But there's also
>> "Principle of Subsidiarity" (example in EU federalism
>> https://en.wikipedia.org/wiki/Subsidiarity ...sort of the "I'm more
>> local than you are" ethic).
>>
>> Damned "nested hierarchies"! http://www.isss.org/hierarchy.htm
>>
>> Joseph Potvin
>>
>> On Tue, Mar 11, 2014 at 11:54 PM, Tim Holborn <timothy.holborn@gmail.com>
>> wrote:
>>
>> Morning / Afternoon All,
>>
>> from a lay-persons point of view; it appears there's about 3 constituents to
>> WebIDl
>>
>> 1. An RDF Ontology (currently pointed at a current version of FOAF).
>> 2. the use of URI's in the Subject Alternative Name Field (which then
>> describes something in some "linked data" compliant manner)
>> 3. the x.509 Certificate, and the manner in how it's been deployed.
>>
>> Herein; i share a few frustrations.
>>
>> My frustration with the ontological preference and vocab; is that when
>> applying identity and use-cases to people and their activities; on Web
>> functional concepts,
>>
>> 1. Describing a Person
>> a. I doubt it's secure to describe myself (akin to a passport) in full in
>> one FOAF document.
>> b. The foaf method doesn't appear to understand 'things' very well; and the
>> language of 'agent' is mixed between 'things' and 'legal entities' (whether
>> person or incorporated legal entity).
>>
>> I have me; I'm happily doing my thing in an array of different groups.
>> Friends, Family, UNI, projects, etc. I have two Facebook accounts, one does
>> activism for social issues; the other is more personal. I have a linkedin
>> account with people i don't want on my Facebook accounts; and i've got an
>> array of other web2 accounts (some i use, some - old IM accounts, forced
>> upon me in new evolutions or left behind in history, without the logs /
>> content). Most people have probably lost data at some point, photos,
>> documents; whether it be due to lightening or lost credentials; the issues
>> are similar to those needed for commerce.
>>
>> Whilst the identity issue has been around for a longtime; it seems it's
>> still knot solved. the most difficult thing about crypto-currency (for
>> example) is the wallet. It's not like i want to participate in supporting
>> another company to act on my behalf (because i'm not able to do it, or not
>> entitled to do so); i rather like the ideas of democracy; and the
>> socio-philosphical view that things invented by humans are there to support
>> humanity, society, environment and the world around us. So, internet
>> identity at some stage needs to be extraordinarily accessible; as as much of
>> a right for a person, as their ability to participate in civics / democracy,
>> even if it's simply walking into a room, declaring their name and being
>> afforded the right to vote.
>>
>> when things start to get more complicated; I'd like to lower the resolution
>> of some results to some groups. If i subscribe to junk mail, or share GPS
>> tagged photos; i might not want to tell them my address, just the state or
>> suburb (district?) i live in. I can understand why it's good to have that
>> data available; but not to everyone for every situation. Therein; there's
>> an array of implications surrounding the description of a person
>> ("FOAF:PERSON") and my view has been that ideally; there's a way to author
>> multiple FOAF files that link via subjects.
>>
>> an early (and very quick) mock-up
>> http://mediaprophet.org/ux_KB/page4115292.html#0 attempted to explore this
>> in a functional orientation.
>>
>> FOAF from what i can understand was essentially first developed to describe
>> a person; but it's branched to be a way to identify an agent, and more
>> complex descriptions than what was first envisaged for the ontology, many,
>> many years ago... Other issues with describing people include describing
>> deceased people, for heritage applications (for example) and the ontology
>> doesn't appear to handle these forms of descriptions of people very well
>> either. If a foaf profile is created for a deceased person - who is
>> authorised to contribute to it. How is that profile enabled to exist;
>> whilst protected from spam.
>>
>> Then from the description of a person (RDF:function); the next constituent,
>> starts to consider that everything on the Web should in theory have an
>> identity; this is important for security, as if i loose my phone it's
>> probably important to identify that a transaction was made by my phone and
>> not by foaf:person. Made by my phone on behalf of foaf:person makes more
>> sense.
>>
>> The same concept applies to companies; where directors of a company have
>> fiduciary duties to that company, the company is not capable of making its
>> own decisions; and workers for that company have an array of expectations
>> put upon them at different stages of the day, the role, etc.
>>
>> Tangentially; - linked to similar considerations; if a worker has a work
>> laptop or device, and works on family stuff at home - is that foaf profile
>> identified as an employee of a company and that profile is bound to a
>> device; are they entitled to humanity, and identity independently if they
>> use that device externally. most people obtain mobile phones on
>> telecommunications plans / contracts, as one potential example. the other
>> of course relates to the cloud storage hosting provider of the data / data
>> service.
>>
>> 2. Describing a legal entity
>> legal entities are people and incorporated legal entities, in the eyes of
>> most systems of law. A person may execute a function on behalf of an
>> incorporated legal entity or on behalf of themselves or someone for whom
>> they are a carer.
>>
>> In my consideration, linguistically, these "roles" are not = agent. where
>> agent may apply (in sociological / legal terms) are situations such as if i
>> have a "role" as a real-estate agent; who has a contract (could be an
>> e-contract) to sell that property (a thing) on behalf of someone else. i
>> believe there are implicit differences between the legal term 'agent' and
>> the functional use of 'agent' in foaf.
>>
>> 3. describing things
>>
>> We've all got a web of things. many want to decentralise and improve our
>> influence over our own data (whilst seeking to broadly support & abide by
>> the rules of our democracies / sovereignty, etc.). Given we're moving
>> towards an world of "linked data", to not acknowledge devices seems foolish.
>> Web of Trust, Web of Thing, Internet of Things = yes, very confusing for a
>> layperson at present. At the end of the day, we'll be centralising info /
>> data, not into a 'trustee' or "Social Network Silo" vendor situation (like
>> web2); but rather to a place that we believe is safe for us to both retain
>> ownership, privacy and other data related considerations; as well as enables
>> us to share with more ease, accountably.
>>
>> Therein; much like we do today; we'll set preferences - Yes, i'm happy for
>> RDF:ontology:label to person / ACL Group / et.al - to access x data assets
>> from my LinkedData Cloud Storage place somewhere, without my explicit human
>> intervention on a request basis.
>>
>> In my view; the permissions chain should acknowledge an array of devices
>> (authentication chain?); and peoples association to those devices. If it's
>> a box at home, it's reasonable to assume the owner of that box has more
>> control, that a shared hosting space somewhere in the world. if the chain is
>> poorly executed; perhaps the reliability of the profile goes down - they're
>> not capable of doing functions that have a requirement of high-level LOI [1]
>> / EoI (evidence of identity) requirement; Equally, authentication chains
>> might be established involving a multitude of ID's (people, companies,
>> things...); or be functional, so a user could set-up some puzzle system
>> where
>> they needed to move their head in front of a camera, tap their phone with a
>> card, then enter a passcode into a specific machine, and say a few magic
>> words, within a pre-defined time-limit on a specified IP or subnet; - for
>> example...
>>
>> If i want to set-up some complex auth chain for supporting specific
>> functions, i should be able to. If i was executing an e-contract on
>> something valuable, it would be important. if i'm adding an acquaintance to
>> an address book; well, i'd make it easy - press the button on my phone...
>>
>> This is not just important for my use specifically; but also in society;
>> We'd likely want the trauma unit of a hospital to have access to the info
>> they need to heal us; and, sharing digital receipt info to our accountant
>> seems practical; but if we change accountants, we'd likely want to revoke
>> access. if a government employee is misappropriating actions that are
>> harmful, perhaps we want a lawyer or our local political member of
>> parliament to have a look at the data in full, and consider the claims, as
>> groups / tagged using metadata perhaps.
>>
>> In theory; the difference between a digital key and a house key - is that a
>> house key is physically programmed and doesn't support reprogramming very
>> well. We'll still need different keys, but the methods relate to identity,
>> which is now described ontologically; and so, underlying all of this is
>> seemingly the ontological issues, not particularly about the method. The
>> method of issues certs bound to a ontology, is dependant upon the ontology.
>>
>> I'd like to see the FOAF ontology improved, rather than replaced. Perhaps
>> this could be done with version control methods....
>>
>> THE CERT
>> the x.509 constituent is only one part of an authentication chain / cycle.
>> To me it issues a certificate to a machine, which then identifies that
>> machine as being "RDF Enabled" (or perhaps rather, the browser / IPv4/IPv6
>> interfaces).
>>
>> I've got several certs in my system; and honestly, it's annoying. I'm the
>> only user on my machine; tried installing a cert at uni - active directory
>> didn't really play well with the concept. i goto play with a RWW server and
>> i've now got several certs to pick from, having to look at the URI's to
>> figure out which one matches the location i'm trying to access.
>>
>> If a person (user / actor) is known to a machine - that should be easier to
>> perform AUTH than someone who is new to a machine. Importantly, a server in
>> effect has a client/server relationship with other servers / services /
>> infrastructure of legal entities.
>>
>> Whether the URI's listed in the x.509v3 certs are specifically FOAF or
>> exclusively FOAF; is another issue again. x.509v3 certs can have a
>> multitude of URI's listed.
>>
>> Foaf spec is: http://xmlns.com/foaf/spec/
>> Foaf Dev list: http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>>
>> IDEAS AROUND SOLUTIONS
>> There's probably two fundamental groups; assets (things; computers,
>> accounts, RFID tags, etc) and entities (legal entities (incorporated,
>> natural)); and then fragmentation within those groups and subgroups.
>>
>> If there's an entirely distributed method to store the 'root' identifier for
>> a person (similar to trying to prevent an foaf:agent from taking someones
>> 'passport') that would be good, but in any case; i'm not the machine /
>> account on a web server somewhere; i'm not a RFID enabled phone or tag; i'm
>> not my computer. I'd like to use these systems in a syndicated methodology
>> to build out systems that are more relevant to me, than those who would like
>> to use me for financial gain (i.e.: becoming an advertiser), as an entire
>> embodiment for any particular request..
>>
>> explaining a solution that is not documented and well understood by
>> specification related resources; will likely be troublesome. in simpler
>> parts of the planet it's difficult to know whether to follow
>> http://www.w3schools.com/ or http://validator.w3.org/ but therein is the
>> ideological concept; which perhaps it's not our role to define, but rather
>> define an inclusive method that supports the differences.
>>
>> i think the use of people for financial gain should be opt-in. I've got a
>> range of views / ideas, that are my own; not the only way of doing things,
>> and i grew-up using english to communicate so i'm kinda affectionate to its
>> traditions of syntax. Spice traders didn't all speak the same language,
>> although i'm rather sure they still had an interest in the semantics of
>> language.
>>
>> In summary; i think the important part is actually on the RDF/FOAF end.
>> forming a common set of values that can be used in a common way,
>> respectfully. I also think it's extremely important that people obtain a
>> digital identity; i believe underlying all the problems, the average person
>> does not have a secure online identity in any manner that would be deemed
>> appropriate for an organisation functioning / exposed / operating with web
>> systems, and of course - this is a multi-faceted issue. x.509v3 elements /
>> WebID is a step in the right direction, IMHO. however, the ontological
>> prescription does trouble me.
>>
>> Sociologically; there's a concept called shared values. if the models right,
>> and the language used doesn't have a predetermined (inappropriate)
>> common-law / legal meaning, i imagine it's highly scalable.
>>
>> Hope theres a contribution in said text; and i hope something therein makes
>> some sense - thanks for listening.
>>
>> Tim Holborn.
>>
>> [1] http://en.wikipedia.org/wiki/Levels_of_Identity_Security
>>
>> On 12 Mar 2014, at 9:30 am, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>
>> On 3/10/14 9:43 PM, Manu Sporny wrote:
>>
>> On 03/05/2014 08:32 AM, Melvin Carvalho wrote:
>>
>> The WebID XG has spent several years trying to come up with
>> definitions for similar concepts. I would veer away from this
>> definition and have
>>
>> 1) an identifier that is a string that identifies an agent (person,
>> or corporation). Formalize this e.g with ABNF
>>
>> The introduction isn't talking about the "identifier URL", it's talking
>> about what a Linked Data identity is about. That said, "identifier URL"
>> is bad, so it should be changed to something else. However, seeing as
>> how the WebID spec already uses the term "WebID" in a way that is very
>> narrow, we can't re-use that term in the Identity Credentials spec. More
>> on this below...
>>
>>
>> An Identifier is a token that denotes (names, refers to, signifies) a
>> referent. It's a critical artifact for enabling identification.
>>
>>
>> 2) I would use the term Profile or Profile Document what what you
>> are calling "An Identity"
>>
>> We did at first, and then figured that it was a bad choice. Why have
>> this distinction? Why are there two concepts for something that only
>> needs one concept? Isn't the only terminology you need something like:
>> "identity" and "identity URL"? Where "identity" is a set of statements
>> about an entity and "identity URL" is the mechanism used to identify a
>> particular identity? More below...
>>
>>
>> Identification is what you get when you construct the description of an
>> entity via the following:
>>
>> 1. an identifier
>> 2. attribute=value pairs that coalesce around an identifier.
>>
>> Net effect, you have a description of the entity denoted by an identifier.
>> Live examples:
>>
>> 1. Passport -- passport number is the identifier around which the claims in
>> the document coalesce
>> 2. Drivers License -- diver's license number is the identifier around which
>> the claims in the document coalesce.
>>
>>
>>
>> WebID A WebID is a URI with an HTTP or HTTPS scheme which denotes an
>> Agent (Person, Organization, Group, Device, etc.). For WebIDs with
>> fragment identifiers (e.g. #me), the URI without the fragment denotes
>> the Profile Document. For WebIDs without fragment identifiers an HTTP
>> request on the WebID /MUST/ return a 303 with a Location header URI
>> referring to the Profile Document.
>>
>> Reasons this is a bad definition:
>>
>> 1. An Agent is something that acts on behalf of another thing. What
>> we're trying to describe here is an entity, not the agent. In other
>> words, an "identity" is a super class of Agent.
>>
>>
>> A WebID is an identifier, in the form of an HTTP URI, that denotes an Agent.
>> It isn't the Agent. It isn't a protocol. It is simply an HTTP URI that
>> offers denotation, like any other HTTP URI, but specifically scoped to
>> agents.
>>
>> Note, HTTP URLs are just HTTP URIs scoped to documents.
>>
>> 2. The whole 303 thing is confusing and will be lost (and not
>> implemented) by developers. The semantic web community really needs to
>> drop the whole 303 redirection thing because it is too esoteric. I'd
>> suggest going with something simpler like:
>>
>> "To make statements about the document at a particular URL, use the
>> #__document pattern."
>>
>>
>> No, folks need to step back, chill out, accept their narratives where
>> utterly broken, and fix the poor narratives that have messed up most routes
>> to comprehension.
>>
>> The whole 303 indirection matter is a consequence of trying to use HTTP URLs
>> where you have WebIDs i.e., trying to use an HTTP URL (without a hash) to
>> denote an Agent or any other entity that isn't a Web Document.
>>
>> This is such a trumped up distraction its untrue.
>>
>>
>> or (and this is a bad idea, but better than 303s):
>>
>> "Statements about the document at a particular URL should associate an
>> rdf:type of xyz:Document. Clients should be sure to never co-mingle
>> statements about a document with any other sort of statement (in other
>> words, enforce provenance for statements about a document)"
>>
>>
>> That's early Gobbledegook from a narrative attempting to tell a story in the
>> worst possible way.
>>
>>
>> What about this instead:
>>
>> "identity"
>> A set of information that can be used to identify a particular entity
>> such as a person, agent, or organization. An entity may have
>> multiple identities associated with it.
>>
>>
>> That's identification.
>>
>>
>> "identity URL"
>> An identity URL consists of an HTTP or HTTPS scheme and denotes an
>> identity.
>>
>>
>> No an HTTP URI denotes (refers to, signifies, or names).
>>
>>
>> "identity document" (don't know if this is necessary)
>> A document that exists at an identity URL and contains statements
>> about an identity.
>>
>>
>> That's identification via claims in a document about what denoted by an
>> Identifier.
>>
>>
>> WebID Profile or Profile Document A WebID Profile is an RDF document
>> which uniquely describes the Agent denoted by the WebID in relation
>> to that WebID. The server /MUST/ provide a |text/turtle| [turtle
>> <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#bib-turtle>]
>>
>>
>> representation of the requested profile. This document /MAY/ be
>>
>> available in other RDF serialization formats, such as RDFa
>> [RDFA-CORE
>> <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#bib-RDFA-CORE>],
>>
>>
>> or [RDF-SYNTAX-GRAMMAR
>>
>> <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#bib-RDF-SYNTAX-GRAMMAR>]
>>
>>
>> if so requested through content negotiation.
>>
>>
>> No, when you use HTTP URIs to denote entities you end up with identifiers
>> that resolve to (or reference) descriptions of their referents. We have a
>> real-world example of this i.e., the different between a word and a term. A
>> term has the dual qualities of denotation and description reference. A word
>> only denotes.
>>
>>
>>
>> There is no need for this definition and no need to tie it to an RDF
>> serialization.
>>
>>
>> RDF too is an eternal distraction, in that pushing it forcefully without
>> coherent justification simply infuriates people. RDF has its unique virtues
>> that manifest when positioned appropriately.
>>
>> So far, we have identifiers and identification. Now, to make identification
>> discernible and comprehensible to both humans and machines, we need to be
>> able to create the the aforementioned attribute=value pairs, that coalesce
>> around an identifier, using an abstract syntax -- one that's brings us close
>> to what we use in the real-world, when constructing sentences and statements
>> i.e, the subject, predicate, object structure which every literate person
>> possess some comprehension of, in their native language.
>>
>> RDF's abstract syntax is the same subject, predicate, object structure from
>> natural language. The subject, predicate, and object components represent
>> entity relationship roles where the participants are denoted using IRIs.
>> Now, if you move this up a notch to Linked Data principles, instead of IRIs,
>> we specifically use HTTP URIs so that we end up with terms instead of words
>> i.e., we make statements instead of sentences. The meaning of every subject,
>> predicate, and object (even when this is a typed or untyped literal) is
>> de-referencable from the identifier used to denote each relationship
>> participant, as represented by the subject, predicate, object abstract
>> syntax.
>>
>> Hopefully, now that we are done with the abstract, we then have to make our
>> identification reusable which requires the durability of a document and the
>> dexterity delivered by representation formats. Basically, this is where
>> RDF's so-called "concrete syntaxes" come into play i.e., you can persist
>> those subject, predicate, and object based statements to:
>>
>> 1. paper ;
>> 2. computer file ;
>>
>> using a variety of notations. Just like the real-world where English,
>> Chinese, French etc.. are for all intents and purposes, just notations.
>>
>> Yes, JSON-LD can be translated into RDF, but it doesn't
>> have to be. Don't provide so many choices and leave it up to content
>> negotiation, while more flexible, that will ensure that there will be
>> divergences in what people implement and thus the whole technology stack
>> required to implement a working system will be more complicated as a
>> result. For example - to implement what's described above, you'll need a
>> TURTLE parser, an RDFa parser, and I presume a JSON-LD parser. What
>> about a NQuads parser? Ntriples?
>>
>>
>> Only when we stop these kinds of debates will we truly make progress. These
>> debates about notations are so broken and distracting, its untrue. Let's
>> stop wasting precious time on these distractions. On the Web you can
>> negotiate the representation of structured data.
>>
>>
>> The definition above would be better, leaving how to fetch the document
>> and the format of the document up to the protocol.
>>
>>
>> We just need to accept that:
>>
>> 1. a WebID is an Identifier
>> 2. a WebID isn't a protocol
>> 3. a WebID is identification and authentication protocol agnostic.
>>
>>
>> Open Questions: 1) JSON LD as a serialization?
>>
>> Yep, there should only be one serialization in order to simplify
>> consumers of the data.
>>
>>
>> NO!
>>
>> Do we have one language spoken by all human beings?
>>
>>
>> 2) mailto: URIs to be included in the definition?
>>
>> No, but you can use a mailto: in a credential such that discovery may
>> still be performed via email address:
>>
>> https://web-payments.org/specs/source/web-identity/#detailed-flow-for-credential-based-login
>>
>>
>> An Email Address is what is claims to be: a URI that denotes the location of
>> a mailbox. Of course, the mailbox itself could be associated with another
>> entity (e.g., its owner) via a relation. That's it.
>>
>>
>> We're currently working on a proposal such that domains that are not
>> email providers may still vouch for an email address. So, for example,
>> you could still login to a website using "melvin@gmail.com", but your
>> personal website "http://melvincarvalho.com/" could still vouch for the
>> email address.
>>
>> We're currently looking into implementing this via a distributed data
>> store potentially built on top of telehash, or some other sort of
>> decentralized identity store.
>>
>>
>> You are mentioning too many MUSTs that utterly break the concepts that
>> underlie the kind of open architecture that AWWW puts on a platter.
>>
>>
>> This approach would allow you to pick your
>> identity provider independently of your email address /and/ not require
>> the sort of centralized infrastructure that is required for Mozilla
>> Persona. This approach might solve the "email provider buy-in" problem
>> that Persona had.
>>
>>
>> Persona is a living example of everything I am trying to warn against. It
>> was broken at inception, for the same reasons: leaky abstraction and failure
>> to accept what AWWW puts on a platter.
>>
>>
>>
>> -- manu
>>
>>
>> Links:
>>
>> [1] http://slidesha.re/1epEyZ1 -- Understanding Data (this presentation
>> covers most of what I've typed in haste in this post re. structured data and
>> RDF)
>> [2] http://bit.ly/1cchBvV -- Glossary of Terms .
>>
>> --
>>
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter Profile: https://twitter.com/kidehen
>> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> http://www.projectmanagementhotel.com/projects/opman-portfolio
> jpotvin@opman.ca
> Mobile: 819-593-5983
> LinkedIn (Google short URL): http://goo.gl/Ssp56
>
>> On Wed, Mar 12, 2014 at 6:26 AM, Tim Holborn <timothy.holborn@gmail.com> wrote:
>> A Supplemental
>>
>> "Senator LUDLAM (Western Australia) (14:08): Mr President, I ask a final
>> supplementary question and we will see if we do any better with this one.
>> Will the Attorney-General assist the Prime Minister to understand what
>> metadata actually is, given he stated yesterday it was simply billing data
>> when in fact metadata reveals mobile and landline phone records, a person's
>> precise location, the source and destination of electronic mail, their
>> entire social network and their web history? Could the Attorney please give
>> an undertaking to remind the Prime Minister of what this term actually
>> means?
>>
>> Senator BRANDIS (Queensland--Deputy Leader of the Government in the Senate,
>> Vice-President of the Executive Council, Minister for Arts and
>> Attorney-General) (14:09): I think the honourable senator, if I may say so,
>> assumes too much, because the term 'metadata' is not a term of art; it is a
>> term that means different things to different people. I can tell the
>> honourable senator that, during the parliamentary inquiry to which I
>> referred in my answer to his first supplementary question, a number of
>> witnesses gave different definitions of what they understood to be metadata.
>> I myself, on the basis of having been informed by the evidence of those
>> several witnesses during the last parliament, thought that the Prime
>> Minister's description of metadata as essentially billing details was a
>> perfectly accurate, shorthand description of what is a contestable concept.
>>
>> source:
>> http://parlinfo.aph.gov.au/parlInfo/search/display/display.w3p;db=CHAMBER;id=chamber%2Fhansards%2F2920c44d-a6eb-4db5-99ca-95422bf3aa7c%2F0022;query=Id%3A%22chamber%2Fhansards%2F2920c44d-a6eb-4db5-99ca-95422bf3aa7c%2F0000%22
>>
>> On 12 Mar 2014, at 7:35 pm, Joseph Potvin <jpotvin@opman.ca> wrote:
>>
>> Tim, Very interesting outline to aid thinking.
>>
>> For anyone in need of a good headache, I'll add that there's a
>> requirement also to take into account some additional meta-layer
>> issues:
>> (a) the allocation of the right/responsibility to choose which aspects
>> of an agent's identity applies to any particular transaction;
>> (b) the allocation of the right/responsibility to choose which
>> jurisdiction's rules govern the allocation of the right/responsibility
>> to choose aspects of an agent's identity that shall apply to
>> transactions or things;
>> (c) the allocation of the right/responsibility to recognize, or to not
>> recognize, jurisdictions.
>>
>> Layer (a) can be considered grounded in the originally French legal
>> concept of "droits morales"
>> http://www.artslaw.com.au/info-sheets/info-sheet/moral-rights/ (for
>> anyone who is not familiar with the terminology context, this is not
>> about "moral=ethical", it is about "morale=attitude" as in the phrase
>> "team morale"). ...though I'll bet it probably all traces back to
>> Aristotle! Here's a summary in Australian (based on Brit) law:
>> http://www.artslaw.com.au/info-sheets/info-sheet/moral-rights/
>>
>> Layer (a) in a web payments realm will include, say, the right to
>> determine whether one's trade is taxable or not (Are "you" or are
>> "you" not "in the business" of fixing bicycles for a living?)
>>
>> Layer (b) has been playing out recently in relation to Bitcoin, which
>> is getting decided not at that realm, but via Layer (c).
>>
>> Layer (c) is determined by legal/ethical "doctrine" or "principle".
>> For example, there's the "Principle of Paramountcy" (example, in
>> Canadian federalism
>> https://en.wikipedia.org/wiki/Paramountcy_%28Canada%29 ... sort of the
>> "I'm more comprehensive than you are" ethic). But there's also
>> "Principle of Subsidiarity" (example in EU federalism
>> https://en.wikipedia.org/wiki/Subsidiarity ...sort of the "I'm more
>> local than you are" ethic).
>>
>> Damned "nested hierarchies"! http://www.isss.org/hierarchy.htm
>>
>> Joseph Potvin
>>
>> On Tue, Mar 11, 2014 at 11:54 PM, Tim Holborn <timothy.holborn@gmail.com>
>> wrote:
>>
>> Morning / Afternoon All,
>>
>> from a lay-persons point of view; it appears there's about 3 constituents to
>> WebIDl
>>
>> 1. An RDF Ontology (currently pointed at a current version of FOAF).
>> 2. the use of URI's in the Subject Alternative Name Field (which then
>> describes something in some "linked data" compliant manner)
>> 3. the x.509 Certificate, and the manner in how it's been deployed.
>>
>> Herein; i share a few frustrations.
>>
>> My frustration with the ontological preference and vocab; is that when
>> applying identity and use-cases to people and their activities; on Web
>> functional concepts,
>>
>> 1. Describing a Person
>> a. I doubt it's secure to describe myself (akin to a passport) in full in
>> one FOAF document.
>> b. The foaf method doesn't appear to understand 'things' very well; and the
>> language of 'agent' is mixed between 'things' and 'legal entities' (whether
>> person or incorporated legal entity).
>>
>> I have me; I'm happily doing my thing in an array of different groups.
>> Friends, Family, UNI, projects, etc. I have two Facebook accounts, one does
>> activism for social issues; the other is more personal. I have a linkedin
>> account with people i don't want on my Facebook accounts; and i've got an
>> array of other web2 accounts (some i use, some - old IM accounts, forced
>> upon me in new evolutions or left behind in history, without the logs /
>> content). Most people have probably lost data at some point, photos,
>> documents; whether it be due to lightening or lost credentials; the issues
>> are similar to those needed for commerce.
>>
>> Whilst the identity issue has been around for a longtime; it seems it's
>> still knot solved. the most difficult thing about crypto-currency (for
>> example) is the wallet. It's not like i want to participate in supporting
>> another company to act on my behalf (because i'm not able to do it, or not
>> entitled to do so); i rather like the ideas of democracy; and the
>> socio-philosphical view that things invented by humans are there to support
>> humanity, society, environment and the world around us. So, internet
>> identity at some stage needs to be extraordinarily accessible; as as much of
>> a right for a person, as their ability to participate in civics / democracy,
>> even if it's simply walking into a room, declaring their name and being
>> afforded the right to vote.
>>
>> when things start to get more complicated; I'd like to lower the resolution
>> of some results to some groups. If i subscribe to junk mail, or share GPS
>> tagged photos; i might not want to tell them my address, just the state or
>> suburb (district?) i live in. I can understand why it's good to have that
>> data available; but not to everyone for every situation. Therein; there's
>> an array of implications surrounding the description of a person
>> ("FOAF:PERSON") and my view has been that ideally; there's a way to author
>> multiple FOAF files that link via subjects.
>>
>> an early (and very quick) mock-up
>> http://mediaprophet.org/ux_KB/page4115292.html#0 attempted to explore this
>> in a functional orientation.
>>
>> FOAF from what i can understand was essentially first developed to describe
>> a person; but it's branched to be a way to identify an agent, and more
>> complex descriptions than what was first envisaged for the ontology, many,
>> many years ago... Other issues with describing people include describing
>> deceased people, for heritage applications (for example) and the ontology
>> doesn't appear to handle these forms of descriptions of people very well
>> either. If a foaf profile is created for a deceased person - who is
>> authorised to contribute to it. How is that profile enabled to exist;
>> whilst protected from spam.
>>
>> Then from the description of a person (RDF:function); the next constituent,
>> starts to consider that everything on the Web should in theory have an
>> identity; this is important for security, as if i loose my phone it's
>> probably important to identify that a transaction was made by my phone and
>> not by foaf:person. Made by my phone on behalf of foaf:person makes more
>> sense.
>>
>> The same concept applies to companies; where directors of a company have
>> fiduciary duties to that company, the company is not capable of making its
>> own decisions; and workers for that company have an array of expectations
>> put upon them at different stages of the day, the role, etc.
>>
>> Tangentially; - linked to similar considerations; if a worker has a work
>> laptop or device, and works on family stuff at home - is that foaf profile
>> identified as an employee of a company and that profile is bound to a
>> device; are they entitled to humanity, and identity independently if they
>> use that device externally. most people obtain mobile phones on
>> telecommunications plans / contracts, as one potential example. the other
>> of course relates to the cloud storage hosting provider of the data / data
>> service.
>>
>> 2. Describing a legal entity
>> legal entities are people and incorporated legal entities, in the eyes of
>> most systems of law. A person may execute a function on behalf of an
>> incorporated legal entity or on behalf of themselves or someone for whom
>> they are a carer.
>>
>> In my consideration, linguistically, these "roles" are not = agent. where
>> agent may apply (in sociological / legal terms) are situations such as if i
>> have a "role" as a real-estate agent; who has a contract (could be an
>> e-contract) to sell that property (a thing) on behalf of someone else. i
>> believe there are implicit differences between the legal term 'agent' and
>> the functional use of 'agent' in foaf.
>>
>> 3. describing things
>>
>> We've all got a web of things. many want to decentralise and improve our
>> influence over our own data (whilst seeking to broadly support & abide by
>> the rules of our democracies / sovereignty, etc.). Given we're moving
>> towards an world of "linked data", to not acknowledge devices seems foolish.
>> Web of Trust, Web of Thing, Internet of Things = yes, very confusing for a
>> layperson at present. At the end of the day, we'll be centralising info /
>> data, not into a 'trustee' or "Social Network Silo" vendor situation (like
>> web2); but rather to a place that we believe is safe for us to both retain
>> ownership, privacy and other data related considerations; as well as enables
>> us to share with more ease, accountably.
>>
>> Therein; much like we do today; we'll set preferences - Yes, i'm happy for
>> RDF:ontology:label to person / ACL Group / et.al - to access x data assets
>> from my LinkedData Cloud Storage place somewhere, without my explicit human
>> intervention on a request basis.
>>
>> In my view; the permissions chain should acknowledge an array of devices
>> (authentication chain?); and peoples association to those devices. If it's
>> a box at home, it's reasonable to assume the owner of that box has more
>> control, that a shared hosting space somewhere in the world. if the chain is
>> poorly executed; perhaps the reliability of the profile goes down - they're
>> not capable of doing functions that have a requirement of high-level LOI [1]
>> / EoI (evidence of identity) requirement; Equally, authentication chains
>> might be established involving a multitude of ID's (people, companies,
>> things...); or be functional, so a user could set-up some puzzle system
>> where
>> they needed to move their head in front of a camera, tap their phone with a
>> card, then enter a passcode into a specific machine, and say a few magic
>> words, within a pre-defined time-limit on a specified IP or subnet; - for
>> example...
>>
>> If i want to set-up some complex auth chain for supporting specific
>> functions, i should be able to. If i was executing an e-contract on
>> something valuable, it would be important. if i'm adding an acquaintance to
>> an address book; well, i'd make it easy - press the button on my phone...
>>
>> This is not just important for my use specifically; but also in society;
>> We'd likely want the trauma unit of a hospital to have access to the info
>> they need to heal us; and, sharing digital receipt info to our accountant
>> seems practical; but if we change accountants, we'd likely want to revoke
>> access. if a government employee is misappropriating actions that are
>> harmful, perhaps we want a lawyer or our local political member of
>> parliament to have a look at the data in full, and consider the claims, as
>> groups / tagged using metadata perhaps.
>>
>> In theory; the difference between a digital key and a house key - is that a
>> house key is physically programmed and doesn't support reprogramming very
>> well. We'll still need different keys, but the methods relate to identity,
>> which is now described ontologically; and so, underlying all of this is
>> seemingly the ontological issues, not particularly about the method. The
>> method of issues certs bound to a ontology, is dependant upon the ontology.
>>
>> I'd like to see the FOAF ontology improved, rather than replaced. Perhaps
>> this could be done with version control methods....
>>
>> THE CERT
>> the x.509 constituent is only one part of an authentication chain / cycle.
>> To me it issues a certificate to a machine, which then identifies that
>> machine as being "RDF Enabled" (or perhaps rather, the browser / IPv4/IPv6
>> interfaces).
>>
>> I've got several certs in my system; and honestly, it's annoying. I'm the
>> only user on my machine; tried installing a cert at uni - active directory
>> didn't really play well with the concept. i goto play with a RWW server and
>> i've now got several certs to pick from, having to look at the URI's to
>> figure out which one matches the location i'm trying to access.
>>
>> If a person (user / actor) is known to a machine - that should be easier to
>> perform AUTH than someone who is new to a machine. Importantly, a server in
>> effect has a client/server relationship with other servers / services /
>> infrastructure of legal entities.
>>
>> Whether the URI's listed in the x.509v3 certs are specifically FOAF or
>> exclusively FOAF; is another issue again. x.509v3 certs can have a
>> multitude of URI's listed.
>>
>> Foaf spec is: http://xmlns.com/foaf/spec/
>> Foaf Dev list: http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>>
>> IDEAS AROUND SOLUTIONS
>> There's probably two fundamental groups; assets (things; computers,
>> accounts, RFID tags, etc) and entities (legal entities (incorporated,
>> natural)); and then fragmentation within those groups and subgroups.
>>
>> If there's an entirely distributed method to store the 'root' identifier for
>> a person (similar to trying to prevent an foaf:agent from taking someones
>> 'passport') that would be good, but in any case; i'm not the machine /
>> account on a web server somewhere; i'm not a RFID enabled phone or tag; i'm
>> not my computer. I'd like to use these systems in a syndicated methodology
>> to build out systems that are more relevant to me, than those who would like
>> to use me for financial gain (i.e.: becoming an advertiser), as an entire
>> embodiment for any particular request..
>>
>> explaining a solution that is not documented and well understood by
>> specification related resources; will likely be troublesome. in simpler
>> parts of the planet it's difficult to know whether to follow
>> http://www.w3schools.com/ or http://validator.w3.org/ but therein is the
>> ideological concept; which perhaps it's not our role to define, but rather
>> define an inclusive method that supports the differences.
>>
>> i think the use of people for financial gain should be opt-in. I've got a
>> range of views / ideas, that are my own; not the only way of doing things,
>> and i grew-up using english to communicate so i'm kinda affectionate to its
>> traditions of syntax. Spice traders didn't all speak the same language,
>> although i'm rather sure they still had an interest in the semantics of
>> language.
>>
>> In summary; i think the important part is actually on the RDF/FOAF end.
>> forming a common set of values that can be used in a common way,
>> respectfully. I also think it's extremely important that people obtain a
>> digital identity; i believe underlying all the problems, the average person
>> does not have a secure online identity in any manner that would be deemed
>> appropriate for an organisation functioning / exposed / operating with web
>> systems, and of course - this is a multi-faceted issue. x.509v3 elements /
>> WebID is a step in the right direction, IMHO. however, the ontological
>> prescription does trouble me.
>>
>> Sociologically; there's a concept called shared values. if the models right,
>> and the language used doesn't have a predetermined (inappropriate)
>> common-law / legal meaning, i imagine it's highly scalable.
>>
>> Hope theres a contribution in said text; and i hope something therein makes
>> some sense - thanks for listening.
>>
>> Tim Holborn.
>>
>> [1] http://en.wikipedia.org/wiki/Levels_of_Identity_Security
>>
>> On 12 Mar 2014, at 9:30 am, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>>
>> On 3/10/14 9:43 PM, Manu Sporny wrote:
>>
>> On 03/05/2014 08:32 AM, Melvin Carvalho wrote:
>>
>> The WebID XG has spent several years trying to come up with
>> definitions for similar concepts. I would veer away from this
>> definition and have
>>
>> 1) an identifier that is a string that identifies an agent (person,
>> or corporation). Formalize this e.g with ABNF
>>
>> The introduction isn't talking about the "identifier URL", it's talking
>> about what a Linked Data identity is about. That said, "identifier URL"
>> is bad, so it should be changed to something else. However, seeing as
>> how the WebID spec already uses the term "WebID" in a way that is very
>> narrow, we can't re-use that term in the Identity Credentials spec. More
>> on this below...
>>
>>
>> An Identifier is a token that denotes (names, refers to, signifies) a
>> referent. It's a critical artifact for enabling identification.
>>
>>
>> 2) I would use the term Profile or Profile Document what what you
>> are calling "An Identity"
>>
>> We did at first, and then figured that it was a bad choice. Why have
>> this distinction? Why are there two concepts for something that only
>> needs one concept? Isn't the only terminology you need something like:
>> "identity" and "identity URL"? Where "identity" is a set of statements
>> about an entity and "identity URL" is the mechanism used to identify a
>> particular identity? More below...
>>
>>
>> Identification is what you get when you construct the description of an
>> entity via the following:
>>
>> 1. an identifier
>> 2. attribute=value pairs that coalesce around an identifier.
>>
>> Net effect, you have a description of the entity denoted by an identifier.
>> Live examples:
>>
>> 1. Passport -- passport number is the identifier around which the claims in
>> the document coalesce
>> 2. Drivers License -- diver's license number is the identifier around which
>> the claims in the document coalesce.
>>
>>
>>
>> WebID A WebID is a URI with an HTTP or HTTPS scheme which denotes an
>> Agent (Person, Organization, Group, Device, etc.). For WebIDs with
>> fragment identifiers (e.g. #me), the URI without the fragment denotes
>> the Profile Document. For WebIDs without fragment identifiers an HTTP
>> request on the WebID /MUST/ return a 303 with a Location header URI
>> referring to the Profile Document.
>>
>> Reasons this is a bad definition:
>>
>> 1. An Agent is something that acts on behalf of another thing. What
>> we're trying to describe here is an entity, not the agent. In other
>> words, an "identity" is a super class of Agent.
>>
>>
>> A WebID is an identifier, in the form of an HTTP URI, that denotes an Agent.
>> It isn't the Agent. It isn't a protocol. It is simply an HTTP URI that
>> offers denotation, like any other HTTP URI, but specifically scoped to
>> agents.
>>
>> Note, HTTP URLs are just HTTP URIs scoped to documents.
>>
>> 2. The whole 303 thing is confusing and will be lost (and not
>> implemented) by developers. The semantic web community really needs to
>> drop the whole 303 redirection thing because it is too esoteric. I'd
>> suggest going with something simpler like:
>>
>> "To make statements about the document at a particular URL, use the
>> #__document pattern."
>>
>>
>> No, folks need to step back, chill out, accept their narratives where
>> utterly broken, and fix the poor narratives that have messed up most routes
>> to comprehension.
>>
>> The whole 303 indirection matter is a consequence of trying to use HTTP URLs
>> where you have WebIDs i.e., trying to use an HTTP URL (without a hash) to
>> denote an Agent or any other entity that isn't a Web Document.
>>
>> This is such a trumped up distraction its untrue.
>>
>>
>> or (and this is a bad idea, but better than 303s):
>>
>> "Statements about the document at a particular URL should associate an
>> rdf:type of xyz:Document. Clients should be sure to never co-mingle
>> statements about a document with any other sort of statement (in other
>> words, enforce provenance for statements about a document)"
>>
>>
>> That's early Gobbledegook from a narrative attempting to tell a story in the
>> worst possible way.
>>
>>
>> What about this instead:
>>
>> "identity"
>> A set of information that can be used to identify a particular entity
>> such as a person, agent, or organization. An entity may have
>> multiple identities associated with it.
>>
>>
>> That's identification.
>>
>>
>> "identity URL"
>> An identity URL consists of an HTTP or HTTPS scheme and denotes an
>> identity.
>>
>>
>> No an HTTP URI denotes (refers to, signifies, or names).
>>
>>
>> "identity document" (don't know if this is necessary)
>> A document that exists at an identity URL and contains statements
>> about an identity.
>>
>>
>> That's identification via claims in a document about what denoted by an
>> Identifier.
>>
>>
>> WebID Profile or Profile Document A WebID Profile is an RDF document
>> which uniquely describes the Agent denoted by the WebID in relation
>> to that WebID. The server /MUST/ provide a |text/turtle| [turtle
>> <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#bib-turtle>]
>>
>>
>> representation of the requested profile. This document /MAY/ be
>>
>> available in other RDF serialization formats, such as RDFa
>> [RDFA-CORE
>> <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#bib-RDFA-CORE>],
>>
>>
>> or [RDF-SYNTAX-GRAMMAR
>>
>> <https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html#bib-RDF-SYNTAX-GRAMMAR>]
>>
>>
>> if so requested through content negotiation.
>>
>>
>> No, when you use HTTP URIs to denote entities you end up with identifiers
>> that resolve to (or reference) descriptions of their referents. We have a
>> real-world example of this i.e., the different between a word and a term. A
>> term has the dual qualities of denotation and description reference. A word
>> only denotes.
>>
>>
>>
>> There is no need for this definition and no need to tie it to an RDF
>> serialization.
>>
>>
>> RDF too is an eternal distraction, in that pushing it forcefully without
>> coherent justification simply infuriates people. RDF has its unique virtues
>> that manifest when positioned appropriately.
>>
>> So far, we have identifiers and identification. Now, to make identification
>> discernible and comprehensible to both humans and machines, we need to be
>> able to create the the aforementioned attribute=value pairs, that coalesce
>> around an identifier, using an abstract syntax -- one that's brings us close
>> to what we use in the real-world, when constructing sentences and statements
>> i.e, the subject, predicate, object structure which every literate person
>> possess some comprehension of, in their native language.
>>
>> RDF's abstract syntax is the same subject, predicate, object structure from
>> natural language. The subject, predicate, and object components represent
>> entity relationship roles where the participants are denoted using IRIs.
>> Now, if you move this up a notch to Linked Data principles, instead of IRIs,
>> we specifically use HTTP URIs so that we end up with terms instead of words
>> i.e., we make statements instead of sentences. The meaning of every subject,
>> predicate, and object (even when this is a typed or untyped literal) is
>> de-referencable from the identifier used to denote each relationship
>> participant, as represented by the subject, predicate, object abstract
>> syntax.
>>
>> Hopefully, now that we are done with the abstract, we then have to make our
>> identification reusable which requires the durability of a document and the
>> dexterity delivered by representation formats. Basically, this is where
>> RDF's so-called "concrete syntaxes" come into play i.e., you can persist
>> those subject, predicate, and object based statements to:
>>
>> 1. paper ;
>> 2. computer file ;
>>
>> using a variety of notations. Just like the real-world where English,
>> Chinese, French etc.. are for all intents and purposes, just notations.
>>
>> Yes, JSON-LD can be translated into RDF, but it doesn't
>> have to be. Don't provide so many choices and leave it up to content
>> negotiation, while more flexible, that will ensure that there will be
>> divergences in what people implement and thus the whole technology stack
>> required to implement a working system will be more complicated as a
>> result. For example - to implement what's described above, you'll need a
>> TURTLE parser, an RDFa parser, and I presume a JSON-LD parser. What
>> about a NQuads parser? Ntriples?
>>
>>
>> Only when we stop these kinds of debates will we truly make progress. These
>> debates about notations are so broken and distracting, its untrue. Let's
>> stop wasting precious time on these distractions. On the Web you can
>> negotiate the representation of structured data.
>>
>>
>> The definition above would be better, leaving how to fetch the document
>> and the format of the document up to the protocol.
>>
>>
>> We just need to accept that:
>>
>> 1. a WebID is an Identifier
>> 2. a WebID isn't a protocol
>> 3. a WebID is identification and authentication protocol agnostic.
>>
>>
>> Open Questions: 1) JSON LD as a serialization?
>>
>> Yep, there should only be one serialization in order to simplify
>> consumers of the data.
>>
>>
>> NO!
>>
>> Do we have one language spoken by all human beings?
>>
>>
>> 2) mailto: URIs to be included in the definition?
>>
>> No, but you can use a mailto: in a credential such that discovery may
>> still be performed via email address:
>>
>> https://web-payments.org/specs/source/web-identity/#detailed-flow-for-credential-based-login
>>
>>
>> An Email Address is what is claims to be: a URI that denotes the location of
>> a mailbox. Of course, the mailbox itself could be associated with another
>> entity (e.g., its owner) via a relation. That's it.
>>
>>
>> We're currently working on a proposal such that domains that are not
>> email providers may still vouch for an email address. So, for example,
>> you could still login to a website using "melvin@gmail.com", but your
>> personal website "http://melvincarvalho.com/" could still vouch for the
>> email address.
>>
>> We're currently looking into implementing this via a distributed data
>> store potentially built on top of telehash, or some other sort of
>> decentralized identity store.
>>
>>
>> You are mentioning too many MUSTs that utterly break the concepts that
>> underlie the kind of open architecture that AWWW puts on a platter.
>>
>>
>> This approach would allow you to pick your
>> identity provider independently of your email address /and/ not require
>> the sort of centralized infrastructure that is required for Mozilla
>> Persona. This approach might solve the "email provider buy-in" problem
>> that Persona had.
>>
>>
>> Persona is a living example of everything I am trying to warn against. It
>> was broken at inception, for the same reasons: leaky abstraction and failure
>> to accept what AWWW puts on a platter.
>>
>>
>>
>> -- manu
>>
>>
>> Links:
>>
>> [1] http://slidesha.re/1epEyZ1 -- Understanding Data (this presentation
>> covers most of what I've typed in haste in this post re. structured data and
>> RDF)
>> [2] http://bit.ly/1cchBvV -- Glossary of Terms .
>>
>> --
>>
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter Profile: https://twitter.com/kidehen
>> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> http://www.projectmanagementhotel.com/projects/opman-portfolio
> jpotvin@opman.ca
> Mobile: 819-593-5983
> LinkedIn (Google short URL): http://goo.gl/Ssp56
Received on Wednesday, 12 March 2014 11:28:54 UTC