melvsterben_thatmustbeme: if you dont intend to ever use an indexical, then you dont need to worry about it ... it's simply a consensus of other people looking at your content
melvsterben_thatmustbeme: the implementors that dont need an indexical wont use it, yes, so consensus is established in that case, the implementors that do need it (like me) can just use #this ... problem solved
melvsterit's needed lets say if you want to *spend* your credits, e.g. reward another person, offer a bounty etc. *within* the system ... withdrawals are only for taking money *out* of the system etc.
rhiaro_Just passing through... melvster where is the #this consensus data coming from? Of the contacts in your foaf file, 14 us #me, 5 use #i, 1 uses #this, 4 use own name/intials and 3 don't use a fragment id
melvsterrhiaro_: I have several thousand profiles using #this already, so does openlink ... im interested in interoperating with openlink and other producers of linked data
rhiaro_Can you point me to the openlink ones? Several thousand that you've created *yourself* from github profiles doesn't necessarily equal consensus..
melvsteressentially ... if you want to participate in indieweb, get a homepage ... if you want to participate in indieweb AND linked data, add an indexical ... if you do that, that's fine -- what would be nice is putting that in the URL field in github so that follow your nose works ... if you dont use an indexical and linked data systems want to create a driver to indieweb data, such as known, it needs to pick one ... #me is a good candidate ... but person spec
melvsterific ... my personal feeling is that #this is going to be the pattern of choice, so that's what im going with so far, unless another pattern emerges, then ill switch
csarvenmelvster I may have missed the background discussion on this but why the concern on the particular string for that fragment? Wouldn't an appropriate property pointing at the resource, and/or the class assigned to that resource be more precise?
csarvenFair enough. I think it is good to explore the options to bootstrap where needed. Do you think that it would be more fruitful to identify those possible approaches before going in more depth?
rhiaro_I would say the url (via url mf2 property) of the representitive h-* on the page is inferred to be the subject URI, rather than it being a b-node. I know this is counter httpRange-14 and would result in things like <http://my-domain.com> mf2:url <http://my-domain.com> but I think it's more useful than blank nodes.
melvstercsarven: what makes sense is to prioritize based on resources, if looking at a given bootstrap target a common practice is helpful imho so you can pre guess what is going to give you the least implementation head ache going forward ...
csarvenAny way, what I'm trying to say is that, perhaps it is best left alone as to what that fragment is, if there is one. No need to hardcode anything. Let mf2 do its own thing, even though it is pretty vague.
csarvenmelvster Difficult to force a URI Template on people. Best left alone. Figure it out on the receiving end. Also consider the possibility that maybe there are resources which do not want to be globally identified!
melvstercsarven: im not doing that ... it's open world assumption ... it's translating legacy data into linked data which could be useful ... in isolation it is useful, if done in a common way it's even more useful, that's about all you can say
melvsterif there is a better suggestion than #this being used for this, id be prepared to switch, but id like to see the evidence and/or reasoning behind it
melvsterfor this, the indieweb use case is much less of a priority than the github use case, because github have about 2.5 million useful profiles and indieweb is a few 1000 mainly in known and various home pages, but hopefully over time those numbers will shoot up and then there's more incentive
melvsterit's also for web 2.0 sites that start getting to know web standards better and say, 'hey linked data is cool how can we become compliant' ... then we can give them simple patterns, point to what has been done so far, show them source code, then they can quickly get on board using cut and paste, and in many cases linked data will already have been supporting their APIs already by pre guessing the choices
melvsterben_thatmustbeme: that does make sense, but I have no idea how hard it is to fix qnames, how long it would take, what tooling breaks etc. qnames dont allow an empty right hand side apparently
melvsterben_thatmustbeme: using # was my suggestion at first too, and how I was coding, but then timbl brought up the qnames thing so I changed my mind ... im not sure how active facebook will be in linked data going forward too, while they are ahead of their rivals im not sure they are doing more R&D in the area as of today
ben_thatmustbeme i think there is a concensus by implementors
melvster essentially ... if you want to participate in indieweb, get a homepage ... if you want to participate in indieweb AND linked data, add an indexical ... if you do that, that's fine -- what would be nice is putting that in the URL field in github so that follow your nose works ... if you dont use an indexical and linked data systems want to create a driver to indieweb data, such as known, it needs to pick one ... #me is a good candidate ... but person spec
rhiaro_ I would say the url (via url mf2 property) of the representitive h-* on the page is inferred to be the subject URI, rather than it being a b-node. I know this is counter httpRange-14 and would result in things like <http://my-domain.com> mf2:url <http://my-domain.com> but I think it's more useful than blank nodes.
csarven http://example.org/# -> this: http://example.org/ -> [this:#]
wseltzer waves to melvster from the Hilton basement